[openstack-dev] Adding GateFailureFix tag to commit messages
mriedem at linux.vnet.ibm.com
Sat Aug 23 23:11:35 UTC 2014
On 8/22/2014 4:11 AM, Daniel P. Berrange wrote:
> On Thu, Aug 21, 2014 at 09:02:17AM -0700, Armando M. wrote:
>> Hi folks,
>> According to , we have ways to introduce external references to commit
>> These are useful to mark certain patches and their relevance in the context
>> of documentation, upgrades, etc.
>> I was wondering if it would be useful considering the addition of another
>> The objective of this tag, mainly for consumption by the review team, would
>> be to make sure that some patches get more attention than others, as they
>> affect the velocity of how certain critical issues are addressed (and gate
>> failures affect everyone).
>> As for machine consumption, I know that some projects use the
>> 'gate-failure' tag to categorize LP bugs that affect the gate. The use of a
>> GateFailureFix tag in the commit message could make the tagging automatic,
>> so that we can keep a log of what all the gate failures are over time.
>> Not sure if this was proposed before, and I welcome any input on the matter.
> We've tried a number of different tags in git commit messages before, in
> an attempt to help prioritization of reviews and unfortunately none of them
> have been particularly successful so far. I think a key reasonsfor this
> is that tags in the commit message are invisible when people are looking at
> lists of possible changes to choose for review. Whether in the gerrit web
> UI reports / dashboards or in command line tools like my own gerrymander,
> reviewers are looking at lists of changes and primarily choosing which
> to review based on the subject line, or other explicitly recorded metadata
> fields. You won't typically look at the commit message until you've already
> decided you want to review the change. So while GateFailureFix may cause
> me to pay more attention during the review of it, it probably won't make
> me start review any sooner.
Yup, I had the same thoughts. The TrivialFix tag idea is similar and
never took off, and I personally don't like that kind of tag anyway
since it's very open to interpretation.
And if GateFailureFix wasn't going to be tied to bug fixes for known
(tracked in elastic-recheck) failures, but just high-priority fixes for
a given project, then it's false advertizing for the change. Gate
failures typically affect all projects, whereas high-priority fixes for
a project might be just isolated to that project, e.g. the recent
testtools 0.9.36 setUp/tearDown and tox hashseed unit test failures are
project-specific and high priority for the project to fix.
If you want a simple way to see high priority bugs that have code out
for review, Tracy Jones has a nice page created for Nova .
More information about the OpenStack-dev