Re: Bugzilla outstanding issues

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

Christopher Blizzard <blizzard redhat com> writes:

> Dan Winship wrote:
> 
> >>     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. :)
> 
> Yeah, this seems pretty important with bugs being assigned to an alias
> that has multiple recipients.  It also means that the nag mail that is
> ( maybe ) sent out every night will be sent to the list and people can
> respond to it.

Ok, I think we can just keep the old setup for this (the MAINTAINERS files
in CVS and the automatically generated aliases).

> >> @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"?
> 
> In the Mozilla world where all this came from, blocker means that
> people will hold the tree closed until a bug gets fixed.  That is, no
> checkins that might further hide the problem until the checkin that
> caused the problem is either fixed or backed out of cvs.
> 
> This is mostly a result of daily verificiation builds of an entire
> "product" and isn't terribly relevant to what gnome is doing since
> there aren't daily builds.

Hmm, then my guess from my last mail really wasn't so wrong. I like the
idea to have a severity for "very important bug, must be fixed immediately
before anything else can be done in the module".

> As to your second question I guess that "trivial" is less important
> than "minor." :)  It's really up to the developer.

Well, I like what Mozilla's bug page says about "trivial": "cosmetic problem
like misspelt words or misaligned text".

> >> @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.)
> 
> There are things in gnome that do have different operating systems
> including win32.  You should add that operating system so that the
> people doing the gtk win32 port can put bugs in the system.  Also,
> there might be problems with XIM on solaris or something that are
> opsys specific.  There really isn't a reason to remove this field if
> it's there already.

Basically we can also keep a complete list of operating systems and `other';
this is something which can really be set automatically - either by bug-buddy
or the web-interface can guess this from the user-agent.

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