[openstack-dev] Unwedging the gate

James E. Blair jeblair at openstack.org
Tue Nov 26 02:14:50 UTC 2013

Joe Gordon <joe.gordon0 at gmail.com> writes:

> On Sun, Nov 24, 2013 at 10:48 PM, Robert Collins
> <robertc at robertcollins.net>wrote:
>> On 25 November 2013 19:25, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>> >
>> >
>> >
>> > On Sun, Nov 24, 2013 at 9:58 PM, Robert Collins <
>> robertc at robertcollins.net>
>> > wrote:
>> >>
>> >> I have a proposal - I think we should mark all recheck bugs critical,
>> >> and the respective project PTLs should actively shop around amongst
>> >> their contributors to get them fixed before other work: we should
>> >> drive the known set of nondeterministic issues down to 0 and keep it
>> >> there.
>> >
>> >
>> >
>> > Yes! In fact we are already working towards that. See
>> >
>> http://lists.openstack.org/pipermail/openstack-dev/2013-November/020048.html
>> Indeed I saw that thread - I think I'm proposing something slightly
>> different, or perhaps 'gate blocking' needs clearing up. Which is -
>> that once we have sufficient evidence to believe there is a
>> nondeterministic bug in trunk, whether or not the gate is obviously
>> suffering, we should consider it critical immediately. I don't think
>> we need 24h action on such bugs at that stage - gate blocking zomg
>> issues obviously do though!
> I see what your saying. That sounds like a good idea, all gate bugs are
> critical, but only zomg gate is bad gets 24h action.

This is fundamentally the same idea -- we're talking about degrees.  And
I'm afraid that the difference in degree between a "gate bug" and a
"zomg gate bug" has more to do with the number of changes in the gate
queue than the bug itself.

So yeah, my proposal is that nondeterministic bugs that show up in the
gate should be marked critical, and the expectation is that PTLs should
help get people assigned to them.

Nondeterministic bugs that show up in the gate with no one working on
them are just waiting for a big queue or another nondetermistic bug to
come along and halt everything.


More information about the OpenStack-dev mailing list