launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 12 January 2011 18:20, Robert Collins <robert.collins@xxxxxxxxxxxxx> wrote:
> I don't have a fixed viewpoint here either; I have a few things that I
> think we need to achieve (which the triage document does mention) -
> but its worth having a specific discussion on them I think...
>
>  - it should be trivial to figure out which bug is best to pop off the
> queue and work on (common case workflow)
>  - bugs that are being worked on right now should be visually distinct
> (e.g. in progress means *In Progress* not *queued for fred*).
>  - we should not put more effort into bucketisation than actually is
> needed to look after ~ 6 months worth of work
>  - we should be able to tell users sensibly where our most important
> bugs are and how deep the queue is
>  - we should be able to say 'bug X now' regardless of where bug X is
> in the system - and see that that has been done in the bug tracker
>
> If we meet all these goals, I'll be happy. I don't fundamentally care
> whether the bug of (oops/regression/timeout) is labelled critical or
> high. I don't believe that having a bucket above that bucket makes
> *any* difference to what we do, or that it affects the goals above:
> because *if* something is a crisis its not going to go into *any*
> bucket, its going to get an engineer interrupted, whatever they are
> doing dropped, and the crisis put into their plate.
>
> Thats *not* the normal workflow and so putting it in a bucket of its
> own makes no difference: the buckets are used solely for:
>  - informing users (and an operational problem showing as critical is
> fine from that angle)
>  - the common case workflow of choosing a new bug *after* finishing
> previous work (and having oops/regression/timeout as 'critical' works
> fine from that perspective too).
>
> So the reason I proposed critical for the oops/regression/timeout bucket is:
>  - thats what I think of them as - critical problems
>  - its what our users think of them as
>  - and it works within the constraints AFAICT

It seems to me that putting oopses etc in High would also meet those
constraints, and it would be a bit more consistent with the normal
practice people are used to in other projects, and with what's been
normal on Launchpad so far.

Like other people I do really feel there's a difference between "oh
shit" bugs and "do this next when you're free" and it's useful to mark
them as such.

You seem to have two axioms here:

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.

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.

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.

-- 
Martin