Re: priorities brain dump [was Re: bug_squad]
- From: Luis Villa <louie ximian com>
- To: bugsquad <gnome-bugsquad gnome org>
- Subject: Re: priorities brain dump [was Re: bug_squad]
- Date: 15 Oct 2002 16:38:38 -0400
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.
> > 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
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
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-
] [Thread Prev