launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Thu, Jan 13, 2011 at 7:43 AM, Gary Poster <gary.poster@xxxxxxxxxxxxx> wrote:
>
> On Jan 12, 2011, at 11:08 AM, Robert Collins wrote:
> ...
>>  - 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 think the vast majority of these oops bugs are truely problematic or
dangerous: there are potential attacks on the zope appserver, for
instance.

The ZeroOopsPolicy in its rationale says we want to get to a steady
state where 'an oops means we need to do something to fix a problem a
user is experiencing' - thats very much not the case today... but
imagine if it was:
 - we'd have no critical bugs most of the time
 - any oops, browser regression or functional regression would be critical
 - and all those things really would be serious.

So to me, what we have now really does match up with 'gee we need to
do these things now'. Its a big list because we let them starve vs
feature work - I think of it as a balloon payment on technical debt.

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

We can, and I'll follow the team / Francis here: but I *truely*
consider all the criticals to be exceptional. None of them are feature
requests, all of them are one of:
 - an OOPS / timeout
 - regression of previously signed off on functionality

@Tim: we get new critical code issues every week (in the sense of
exceptional things we need to do now). We have critical *incidents* at
least once a month which are (sometimes) code bugs, and easily
represented by a critical bug immediately assigned to an engineer.

-Rob