[openstack-dev] [openstack-infra] [neutron] Third Party CI Voting
sorlando at nicira.com
Thu Jun 25 22:44:50 UTC 2015
in a nutshell my point is that if we want to remove voting rights from
every CI I'm fine with it.
However, I think what's being discussed in this thread is already captured
very well by  and believe the policy it outlines is perfectly fine for
On 25 June 2015 at 17:08, Edgar Magana <edgar.magana at workday.com> wrote:
> 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
> On 25 June 2015 at 16:08, John Davidge (jodavidg) <jodavidg at cisco.com>
>> 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
> 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
> 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)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev