On 8/22/2014 4:11 AM, Daniel P. Berrange wrote:
On Thu, Aug 21, 2014 at 09:02:17AM -0700, Armando M. wrote:
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 .
OpenStack-dev mailing list