Re: Bugzilla outstanding issues

[Christopher Blizzard <blizzard redhat com>]

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.

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

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

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

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

Yep.

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

It's not hard to remove a keyword from a bug.  It's trivial ( as opposed 
to minor. )

--Chris

--
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
------------