launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

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.  

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 

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

Gary