Re: priorities brain dump [was Re: bug_squad]

[Telsa Gwynne <hobbit aloss ukuu org uk>]

On Mon, Sep 16, 2002 at 04:10:13PM -0400 or thereabouts, Luis Villa wrote:
> BTW, sorry for the cruddy formatting... was experimenting with evo 1.1's
> very cool html cut-and-paste and didn't think of what the possible
> outcomes were in plain text emails. I'll reformat/resend if anyone wants
> me to.

Pah. jdub has taught me a neat vim macro to do this. Now if only
I could remember it... 

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

> that are extremely 'unprofessional'- spelling errors, for example. 
> A challenge for us going forward is how to deal with a11y and 
> usability issues in this framework; stability and polish are
> long-understood and entrenched issues while a11y and usability 
> are not.]

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

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

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

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

Telsa