> 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.


>         -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

Reply via email to