[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