[openstack-dev] [all] 3rd Party CI vs. Gerrit

James E. Blair corvus at inaugust.com
Wed Aug 13 23:22:49 UTC 2014


Chmouel Boudjnah <chmouel at enovance.com> writes:

> On Wed, Aug 13, 2014 at 6:27 PM, James E. Blair <corvus at inaugust.com> wrote:
>
>> If it is not worth looking at a job that is run by the OpenStack CI
>> system, please propose a patch to openstack-infra/config to delete it
>> from the Zuul config.  We only want to run what's useful, and we have
>> other methods (the silent and experimental queues) to develop new jobs
>> without creating noise.
>>
>> If there is a third-party CI system reporting non-voting jobs, um, I
>> don't know what that means.  If it bothers you, you might ask the
>> third-party CI system to disable them and if they don't, then ask us to
>> disable the third-party CI system.
>
> I didn't meant that they were not worthwhile to look at I was just thinking
> it could be useful to sort them so we can easily identify from a UI
> perspective which one was voting or not.

I think part of why I responded with that is because this is not the
first time I have heard someone say they don't want to see the
non-voting jobs.  If that's a real desire, we should get to the bottom
of it.  We don't actually want the CI system to be annoying.  :)

>From my perspective, anything red should represent something that
someone needs to process and either correct or make an informed decision
to ignore.  That is, a failing non-voting job should either cause the
submitter to fix a problem with their code (same as a failing voting
job), or investigate the result and determine that in this case, the
non-voting job can be safely ignored (ie, is an expected result of the
change).

If we have non-voting jobs that don't match that criteria, we should
remove them.  Or make them voting.

-Jim



More information about the OpenStack-dev mailing list