Re: priorities brain dump [was Re: bug_squad]

[Luis Villa <louie ximian com>]

On Tue, 2002-09-17 at 03:51, Telsa Gwynne wrote:
> Anyway, I trimmed the ones I didn't have comments on.
> 
> > http://bugzilla.gnome.org/bug_status.html#severity
> > Priority
> >              Immediate
> > This bug blocks development or testing work and should be fixed
> > ASAP, or is a security issue in a released version of the software.
> > [clarification: basically never used; outside of 'real' security
> > issues, the biggest issue would be 'HEAD X doesn't build because 
> > of a patch.' 'HEAD doesn't build because  my development setup is 
> > broken' or 'HEAD doesn't build because I'm trying to build on some 
> > completely unsupported platform' is /not/  immediate.]
> 
> An observation: we have actually had bugs that would be classed
> as immediate. But when someone checks in something that breaks
> CVS, or there is a security issue, I think people immediately
> mail the committer, often cc'ing g-h; or they grab them on IRC.
> So it's not that bugzilla doesn't need this. It's more that
> such issues tend not to get into bugzilla. 

<nod>

> >                 High
> > Seriously broken, but not as high impact. Should be fixed before 
> > next major release. Can include cosmetic bugs of particularly high
> > visibility, regressions from functionality provided in previous
> > releases, and more minor bugs that are frequently reported. [All
> > crashers, at least at first, should go here. 'high visibility' in 
> > this context mainly means nautilus and panel- things that every 
> > gnome user is going to use every day. It also includes things 
> 
> It's not a universally-agreed sentiment, I suspect, but I would
> also put gnome-terminal in the category of high visibility. Not
> necessarily to "normal users", but certainly to sysadmins and
> developers. 

Very reasonable. Note that /all/ apps can have 'high' bugs- it's just
that a panel/nautilus/terminal bug is more visible and hence a more
minor bug might still be 'high' for our purposes.

> >                Normal
> > Either a fairly straightforward workaround exists or the
> > functionality is not very importantand/or not frequently used. 
> > [This really needs to be rewritten...
> 
> "Where most non-crashy bugs start out"? I think it might best
> be done by examples.

Yeah. Got some examples? Or am I'm going to have to think of them
myself? :) ['most non-crash bugs belong here' might be a pretty good
place to start, examples or no examples.]

> >                 Low
> > Just not all that important; fix when time permits. [mostly
> > crack-headed enhancements, but might also include, say, bugs 
> > against a soon-to-be obsoleted module.]
> 
> Not just that, though? Affects features which few people use.

<nod> I think this wording affects my dislike of saying 'your request
just isn't important.' Probably that's something I should get over.

> > Severity
> > 
> >               Blocker
> > We should fix and push an update immediately. This will mostly be
> > used for security fixes. [comment: this is misnamed, as urgent/
> > immediate are the 'true' release blockers, typically. Perhaps
> > this should be renamed to 'security' or something like that?]
> 
> I can't remember why blocker went in. I imagine there was a reason
> once. 

Probably that's what mozilla did. Does anyone object to the renaming?

> >               Critical
> > crashes, loss of data, severe memory leak. [comment: basically, only
> > crashers. 'Something really big breaks' should be major severity and
> > high priority. This maybe indicates a need to re-name critical to
> > crasher, as I've discussed on this> list before. Thoughts on that?]
> 
> How about an app which leaks memory slowly but which is not used
> by everyone? That would be critical for that app, but might not 
> be a high priority.

Slow leaks would be appropriate here if the app tends to be used for
extended periods- terminals, nautilus, etc. slow leak in the run dialog
probably wouldn't be appropriate. That said, renaming from critical to
'crasher/leaker' or some such might make that more clear?

Thanks for the response, Telsa- hope we can keep this ball rolling until
we actually rewrite the stuff on the bugzilla page-
Luis