[openstack-dev] [gate] The gate: a failure analysis
Jay Pipes
jaypipes at gmail.com
Tue Jul 22 15:51:59 UTC 2014
On 07/22/2014 10:48 AM, Chris Friesen wrote:
> On 07/21/2014 12:03 PM, Clint Byrum wrote:
>> Thanks Matthew for the analysis.
>>
>> I think you missed something though.
>>
>> Right now the frustration is that unrelated intermittent bugs stop your
>> presumably good change from getting in.
>>
>> Without gating, the result would be that even more bugs, many of them not
>> intermittent at all, would get in. Right now, the one random developer
>> who has to hunt down the rechecks and do them is inconvenienced. But
>> without a gate, _every single_ developer will be inconvenienced until
>> the fix is merged.
>
> The problem I see with this is that it's fundamentally not a fair system.
>
> If someone is trying to fix a bug in the libvirt driver, it's wrong to
> expect them to try to debug issues with neutron being unstable. They
> likely don't have the skillset to do it, and we shouldn't expect them to
> do so. It's a waste of developer time.
Who is expecting the developer to debug issues with Neutron? It may be a
waste of developer time to constantly recheck certain bugs (or no bug),
but nobody is saying to the contributor of a libvirt fix "Hey, this
unrelated Neutron bug is causing a failure, so go fix it."
The point of the gate is specifically to provide the sort of rigidity
that unfortunately manifests itself in discomfort from developers.
Perhaps you don't have the history of when we had no strict gate, and it
was a frequent source of frustration that code would sail through to
master that would routinely break master and branches of other OpenStack
projects. I, for one, don't want to revisit the bad old days. As much as
a pain it is, the gate failures are a thorn in the side of folks
precisely to push folks to fix the valid bugs that they highlight. What
we need, like Sean said, is more folks fixing bugs and less folks
working on features and vendor drivers.
Perhaps we, as a community, should make the bug triaging and fixing days
a much more common thing? Maybe make Thursdays or Fridays dedicated bug
days? How about monetary bug bounties being paid out by the OpenStack
Foundation, with a payout scale based on the bug severity and
importance? How about having dedicated bug-squashing teams that focus on
a particular area of the code, that share their status reports at weekly
meetings and on the ML?
best,
-jay
More information about the OpenStack-dev
mailing list