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 [email protected]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
