Re: Bugzilla outstanding issues

[Martin Baulig <martin home-of-linux org>]

Dan Winship <danw helixcode com> writes:

> >     We need to discuss whether we want to have some
> >     <package>-maint bugzilla gnome org mail aliases
> >     for package maintainers like we had with the old
> >     bug tracker or whether we want to have all bugs
> >     assigned to individual persons.
> 
> As the person who all evolution-mail bugs get assigned to by default
> at Helix Code, I vote for package-maint aliases. First, because then
> everyone on the list can get the mail when a bug is added, and second,
> because it makes it easier to see what a person is really working on.
> (Theoretically, you can do this at bugzilla.helixcode.com by seeing
> which bugs are "NEW danw" vs "ASSIGNED danw", but no one other than me
> ever seems to notice this distinction. :)

Yes, this also makes sense for other large packages such as gnome-applets.

> > @severities = (
> >         "blocker",
> >         "critical",
> >         "major",
> >         "normal",
> >         "minor",
> >         "trivial",
> >         "enhancement"
> > );
> 
> What do these all mean? Does the separation of "blocker" and
> "critical" mean that we'll ship packages with "critical" bugs, and if
> so, what does "critical" mean? What's the useful distinction between
> "minor" and "trivial"?

>From the Mozilla bug page:

---
    Blocker
            Blocks development and/or testing work 
    Critical
            crashes, loss of data, severe memory leak 
    Major
            major loss of function 
    Minor
            minor loss of function, or other problem
            where easy workaround is present 
    Trivial
            cosmetic problem like misspelt words or
            misaligned text 
    Enhancement
            Request for enhancement 
---

So we should draw the line of whether a bug "blocks" a release between
Minor and Major (so a release may contain `Minor' bugs, but no `Major'
or above).

Blocker should be reserved for very extreme cases - such as when you can't
even test/fix other stuff in a module before this bug is fixed.

> > @opsys = (
> 
> I don't think we want/need this, or platform. Yeah, there will be bugs
> that affect Solaris and not Linux, but you can just mention that in
> the bug description, which people have done with the current system,
> and I don't think it's been a problem. (The distinction makes much
> more sense in Mozilla-land, where you have vastly separate Unix, Mac,
> and Windows ports, and people working on one are likely to be
> completely unable to do anything about bugs that are specific to
> another.)

Platform probably doesn't make much sense, but I think we should at least
keep `Linux' and `other', maybe also Solaris and BSD.

There are things like for instance some applets or configuration issues
where it makes a difference whether you're on Linux or not.

> >         trash   - Bug report was closed because it was crap/useless etc.,
> >                   set this keyword to distinguish it from other closed
> >                   bug reports so we can exclude them in queries
> 
> Bugzilla already has this. You mark the bug "INVALID" rather than
> "RESOLVED".

Oh, forgot this.

> 
> >         helpwanted - Developer is looking for someone to help him with this
> >                      bug report, for instance because he don't have time or
> >                      he's unable to fix it himself
> 
> Hm... but you said it's hard to remove a keyword from a bug? Seems
> like you might want to remove this after a while.

Oh, this was confusing - I meant that it is hard to remove (better: "destroy"
or even "finalize") a keyword (from the list of valid keywords) since you need
to remove it from all bugs before you can do this.

Of cause you can add/remove keywords from bugs as much as you want.

> If you import the Eazel "inclination" hack, then that can convey
> similar information.

Well, from the developer's point of view this is nice, but doesn't this sound
rude to the bug reporter if you set "I hate this bug" just because you want
someone else to fix it (while it's still a good, valuable bug report).

> >         frequently-reported - This keyword should only be set by the
> 
> Nice!

Maybe we can also make some kind of "Known Problems" page or file which can
be used in bug-buddy.

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)