[openstack-dev] [openstack-infra] [neutron] Third Party CI Voting

Edgar Magana edgar.magana at workday.com
Thu Jun 25 15:08:56 UTC 2015

Thank for your response Salvatore. I am not sure what is your position in this topic? Are you fine removing voting rights to all Cis?


From: Salvatore Orlando
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Thursday, June 25, 2015 at 7:59 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [openstack-infra] [neutron] Third Party CI Voting

On 25 June 2015 at 16:08, John Davidge (jodavidg) <jodavidg at cisco.com<mailto:jodavidg at cisco.com>> wrote:
Hi all,

Recent neutron third party CI issues have got me thinking again about a topic which we discussed in Vancouver:

Should any Third Party CI have voting rights for neutron patches in gerrit?

Why should this be a decision for Neutron only?

I’d like to suggest that they shouldn’t.

A -1 from a third party CI tool can often be an indication that the CI tool itself or the third party plugin is broken, rather than there being issues with the patch under review. I don’t think there are many cases where a third party CI tool has caught a genuine issue that Jenkins has missed. With the current voting rights these CI tools cause a lot of noise when they experience problems.

As far as I am aware no 3rd party CI tool has a better coverage than the upstream one.
some 3rd party CIs exercise different code paths and might uncover some issue that the upstream CI did not cover. There will surely be people claiming this has happened a lot of times, and even a single issue found is invaluable; I would agree with that, but I also think that a 3rd party CI does not have to vote to be useful.

I’m not suggesting that the results of these tests be removed from the page altogether - there are some cases where their results are useful to the patch author/reviewer - but removing voting rights (or at least -1 rights) would save a patch from a –1 that might not be particularly meaningful.

Frankly I find the overwhelming number of CI messages - and email notifications even more annoying that random -1s. Thankfully you can hide the formers and filter out the latters.
From the perspective of 3rd party CI maintainer I could use myself as an example; I maintain a CI which has now been broken for about 48 hours. I am busy with other tasks and cannot look at it now. I might be a terrible person for this, but that's my problem. If the CI was not voting at least I would not have annoyed people. (fwiw, I've disabled my CI now).

Also, I believe we already agreed that a working CI is not anymore a requirement, as long as the plugin/driver maintainers can provide a reasonable proof that their integration works?




OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150625/56fa3faf/attachment.html>

More information about the OpenStack-dev mailing list