launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

On January 12, 2011, Gary Poster wrote:
> On Jan 12, 2011, at 11:08 AM, Robert Collins wrote:
> > Francis gave the nod to activate the new bug triage process we
> > discussed over the last few week or so. I've refreshed the wiki page
> > and folded all the feedback (I think) into it; please fix if its wrong
> > or confusing!
> 
> Thank you.
> 
> ...
> 
> >  - critical means 'a bug to take next' not 'a bug to interrupt
> > 
> > current work' : we use incidents if we need to interrupt work (and
> > Francis is updating that separate policy)
> 
> I'm sorry to raise this after the fact, but sometimes seeing a policy
> implemented shows concerns that had not been seen before.
> 
> On the team lead call we discussed the fact that some bugs are more
> critical than others.  In particular, IMO, while we have so many legacy
> OOPSes, the OOPS bugs, all critical, are going to obscure bugs that truly
> are problematic or potentially dangerous.

I'm not opposed to your suggestion below, but I wonder really how this is 
different than the current existing situation.  Up to now, all 
OOPSes/Timeouts/Regressions were High, and that already mixed legacy and more-
recent-probably-should-be-fixed-sooner ones. We don't mark OOPSes as Critical, 
unless they are related to an operational incident in which case, incident 
handling operation apply. And I'd say that of incident-related bugs, OOPSes 
are a minority. So in a way, this change doesn't really change much, apart the 
fact that it does make in the absolute OOPS/Timeout/Regression more important 
than other bugs (Critical vs High were previously we had only High).

> 
> We can come up with another mechanism other than priority to communicate
> this, but why?  It makes it harder to use the tools.
> 
> I'd prefer if we still have a Critical importance that has some kind of
> "exceptional" semantic and possibly a fairly hard, small limit for how
> many should be a part of them.
> 
> As a relatively-easy-to-implement change and a strawman, could we move most
> of the current rules for High -> Medium, Critical -> High, and Critical to
> a limited set, defined in some way like the old critical policy of
> "imminent (possible or certain) significant danger"?  Perhaps we can
> schedule a revisit when we have OOPS bugs down
> 

Like I said, I think that could work. But it does increase the number of 
relevant buckets in triaging from 3 to 4. 

> ...
> 
> > I'm not sure /who/ is meant to triage day to day, that hasn't really
> > been talked about AFAICT.
> 
> I thought getting the triage done (directly or indirectly) was the
> responsibility of the team leads on bug rotation.

It's the responsibility of the maintenance squads to get it done. How they 
actually implement it is left open-ended for the moment. It could be done by 
the squad leads or it could be done by some engineers or a rotation. I don't 
think we should set it in stone at this stage, let's see how these squads 
self-organized :-)



-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.