Re: [openstack-dev] Adding GateFailureFix tag to commit messages

2014-08-23 Thread Matt Riedemann



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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Adding GateFailureFix tag to commit messages

2014-08-23 Thread Matt Riedemann



On 8/21/2014 11:55 AM, Sean Dague wrote:

On 08/21/2014 11:02 AM, 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.


A concern with this approach is it's pretty arbitrary, and not always
clear which bugs are being addressed and how severe they are.

An idea that came up in the Infra/QA meetup was to build a custom review
dashboard based on the bug list in elastic recheck. That would also
encourage people to categorize this bugs through that system, and I
think provide a virtuous circle around identifying the issues at hand.

I think Joe Gordon had a first pass at this, but I'd be more interested
in doing it this way because it means the patch author fixing a bug just
needs to know they are fixing the bug. Whether or not it's currently a
gate issue would be decided not by the commit message (static) but by
our system that understands what are the gate issues *right now* (dynamic).

-Sean



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Joe's change has merged:

https://review.openstack.org/#/c/109144/

There should be an Open reviews section in the elastic-recheck status 
page now:


http://status.openstack.org/elastic-recheck/

--

Thanks,

Matt Riedemann


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Adding GateFailureFix tag to commit messages

2014-08-23 Thread Joe Gordon
On Fri, Aug 22, 2014 at 2:11 AM, Daniel P. Berrange berra...@redhat.com
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.



gerrit supports searching by message (although the searching is a little
odd sometimes) and these can be used in dashboards.

message:'MESSAGE'

Changes that match *MESSAGE* arbitrary string in the commit message body.



https://review.openstack.org/Documentation/user-search.html

Examples:

https://review.openstack.org/#/q/message:%22UpgradeImpact%22+is:open,n,z
https://review.openstack.org/#/q/message:%22DocImpact%22+is:open,n,z



 Regards,
 Daniel
 --
 |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
 :|
 |: http://libvirt.org  -o- http://virt-manager.org
 :|
 |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
 :|
 |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
 :|

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Adding GateFailureFix tag to commit messages

2014-08-22 Thread Daniel P. Berrange
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
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Adding GateFailureFix tag to commit messages

2014-08-21 Thread Sean Dague
On 08/21/2014 11:02 AM, 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.

A concern with this approach is it's pretty arbitrary, and not always
clear which bugs are being addressed and how severe they are.

An idea that came up in the Infra/QA meetup was to build a custom review
dashboard based on the bug list in elastic recheck. That would also
encourage people to categorize this bugs through that system, and I
think provide a virtuous circle around identifying the issues at hand.

I think Joe Gordon had a first pass at this, but I'd be more interested
in doing it this way because it means the patch author fixing a bug just
needs to know they are fixing the bug. Whether or not it's currently a
gate issue would be decided not by the commit message (static) but by
our system that understands what are the gate issues *right now* (dynamic).

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Adding GateFailureFix tag to commit messages

2014-08-21 Thread Armando M.

 A concern with this approach is it's pretty arbitrary, and not always
 clear which bugs are being addressed and how severe they are.


Well, establishing whether LP reports are actual bugs and assigning the
severity isn't what triaging is for?



 An idea that came up in the Infra/QA meetup was to build a custom review
 dashboard based on the bug list in elastic recheck. That would also
 encourage people to categorize this bugs through that system, and I
 think provide a virtuous circle around identifying the issues at hand.


Having elastic recheck means that the bug has already being vetted, that a
fingerprint for the bug has been filed etc. Granted some gate failures may
be long lasting, but I was hoping this mechanism would target those
failures that are fixed fairly quickly.



 I think Joe Gordon had a first pass at this, but I'd be more interested
 in doing it this way because it means the patch author fixing a bug just
 needs to know they are fixing the bug. Whether or not it's currently a
 gate issue would be decided not by the commit message (static) but by
 our system that understands what are the gate issues *right now* (dynamic).


Gate failures are not exactly low-hanging fruits so it's likely that the
author of the patch already knows that he's fixing a severe issue. The tag
would be an alert for other reviewers so that they can give the patch more
attention. As a core reviewer, I welcome any proposal that wouldn't cause a
reviewer to switch across yet another dashboard, as we already have plenty
(but maybe that's just me).

Having said that, it sounds like you guys have already thought about this,
so it makes sense to discard this idea.

Thanks,
Armando


 -Sean

 --
 Sean Dague
 http://dague.net


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev