Open Stack

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 [1], we have ways to introduce external references to commit
>> messages.
>>
>> 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
>> tag:
>>
>> GateFailureFix
>>
>> 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.
>
> Regards,
> Daniel
>

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 [1].

[1] http://54.201.139.117/nova-bugs.html

-- 

Thanks,

Matt Riedemann