launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Thursday 13 January 2011 01:10:48 Martin Pool wrote:
> 1- Real emergencies are 'off the scale' and almost don't need to be in
> the bug tracker, or at least don't need to be marked specially severe
> in the bug tracker.
> 
> I don't really buy this.  Sometimes time does pass with critical
> issues still open; you can't assume people will just know and not
> forget or have to leave work.  I think it's very good there be an
> obvious flashing light in the bug tracker when something is critical,
> and that that light not be on every day of the year.  (I realize there
> are also irc topics etc.)  If something is severely broken just being
> able to find it by clicking 'critical' is highly useful.  I think it's
> good people jump when a bug is marked critical, and not see that as
> just the normal state.

I agree with this.

Rob also said:
> Launchpad isn't where operational issues are tracked. Such issues
> are tracked in request tracker, and reserving space in Launchpad for
> operational issues doesn't make any sense to me at all.

Not all critical issues are operational problems though.  I want to be able to 
track code fixes to any kind of issue in the bug tracker.  We also *require* a 
bug in regard to our current QA procedures.

If you want to track it in the Request Tracker as well, then I guess that's OK 
but I consider RTs for an entirely different class of problem - that is 
problems that are not in LP's code and require admin intervention.

> 2- If oopses/regressions/timeouts are only marked High not Critical,
> they won't be taken seriously by developers.
> 
> I don't know.  Bit depressing if that's true.

I think that's not true.

Isn't it about time we really started using the various levels of importance 
we have in our bug tracker?  Here's my suggestion:

Low - acknowledged it's a bug, but not important to fix
Medium - we want to fix this but it's behind more important stuff
High - oopses, timeouts, important stuff to do next
Critical - ZOMG drop everything and fix now, incident

Oh and I generally use "wishlist" as a status meaning I don't want to fix this 
bug at all but I also don't want to piss off the bug reporter by flagging it 
as such.

So the only change we'd need to make from how it is now is that a lot of our 
bugs are not really high priority.  I think this accurately reflects reality.

> 
> 3- Our users won't believe we're serious about timeouts unless we mark
> them Critical.
> 
> They'll know we're serious if they get fixed.

Indeed.