<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class=""><div class="h5"><span style="color:rgb(34,34,34)">A concern with this approach is it's pretty arbitrary, and not always</span><br></div></div>
clear which bugs are being addressed and how severe they are.<br></blockquote><div><br></div><div>Well, establishing whether LP reports are actual bugs and assigning the severity isn't what triaging is for?</div><div>

 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
An idea that came up in the Infra/QA meetup was to build a custom review<br>
dashboard based on the bug list in elastic recheck. That would also<br>
encourage people to categorize this bugs through that system, and I<br>
think provide a virtuous circle around identifying the issues at hand.<br></blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I think Joe Gordon had a first pass at this, but I'd be more interested<br>
in doing it this way because it means the patch author fixing a bug just<br>
needs to know they are fixing the bug. Whether or not it's currently a<br>
gate issue would be decided not by the commit message (static) but by<br>
our system that understands what are the gate issues *right now* (dynamic).<br></blockquote><div><br></div><div>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).</div>

<div><br></div><div>Having said that, it sounds like you guys have already thought about this, so it makes sense to discard this idea.</div><div><br></div><div>Thanks,</div><div>Armando</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<span class=""><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>