Re: Bugzilla outstanding issues

[Owen Taylor <otaylor redhat com>]

Martin Baulig <martin home-of-linux org> writes:

> 1.) Maintainers
> 
>     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.

I think we should set it up so that the -maint aliases
always get notifications, even if the bugs are assigned
to a particular person. Otherwise, you risk having the
assignee disappear, and nobody left to pay attention
to changes to the bug.
 
> 2.) Fields
> 
>     bugzilla.eazel.com has a very nice `Inclination'
>     fields where developers can mark that they want
>     to get rid of a bug report, do we want to use this
>     as well ?

Hmmm, I think it is just excess confusion for people looking
at the system. For most packages, bugs will be self-assigned and if you hate
a bug, you'll just leave it in the new state.

>     Are there any other fields we want to change/add ?
> 
> @severities = (
>         "blocker",
>         "critical",
>         "major",
>         "normal",
>         "minor",
>         "trivial",
>         "enhancement"
> );

> @priorities = (
>         "P1",
>         "P2",
>         "P3",
>         "P4",
>         "P5"
> );

Priorities should be named, since P1...P5 don't even say whether
P1 or P5 is more prioritized. How about something like:

 Release Critical, High, Normal, Low
 
The priority/serverity area is rather troublesome - I'm not particularly
happy with any scheme that Havoc and I could come up with.

As a theoretical framework, there are two independent axis that
describe the bug:

 - How much the bug affects the user  (Severity)
 - How much work the bug will take to fix (Time to fix)

Priority is just a computed function of these two, but a function
that pretty much has to be computed by hand.

Having all three fields is definitely confusing, since there is
duplicated information; however someone accessing the bug database may
want to see and/or search on any of the three.

Severity is the least useful, but can be important at times - a
minimum of being able mark a bug as wishlist is important.  It might
be possible to just use a keyword for wishlist, but the bugzilla UI
for keywords is obscure. Having only a few options for the Severity
field - it could be as few as "Wishlist, Normal, Security" - and also
perhaps renaming it to "Type" might help.

The time to fix is probably less useful in a open-source
project where the developers assign priorities themself than in a
commercial project where someone else probably will be assigning
priorities, however it can be useful for someone going along looking
for easy stuff to fix.

So, I'm not really sure what to suggest here - perhaps simply having
all three. One could hope that three clearly defined simple categories
is less confusing than two categories that muddle things together.


> @opsys = (
>         "All",
>         "AIX",
>         "BSDI",
>         "HP-UX",
>         "IRIX",
>         "Linux",
>         "FreeBSD",
>         "OSF/1",
>         "Solaris",
>         "SunOS",
>         "other"
> );
> 
> @platforms = (
>         "All",
>         "DEC",
>         "HP",
>         "Macintosh",
>         "PC",
>         "SGI",
>         "Sun",
>         "Other"
> );

Opsys and platform definitely need to be reworked, what 
I would suggest is:

 Operating System
 ----------------
 Linux
 Solaris
 Windows  [ Yes, we get windows bugs for GTK+ ]

And a text field for operating system details  (Red Hat Linux 7.0, i386)

The architecture, vendor, and OS version details are often important,
but making them enumertaions makes things too complex, and we'll never
successfully track all possible variants.

(Bastille Linux for S/390... version 1.32beta1)

> 4.) Keywords
> 
>     It's easy to add new keywords, but more difficult to remove them
>     later, so which keywords do we want to have ?
> 
>     I'd suggest the following list:
> 
>         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

Bad name - while a lot of useless bugs are basically empty and
never followed up on, there's a pretty good certaintanty that _someone_
will notice their bug marked as "trash". If you want this keyword,
I'd suggest "incomplete.
 
>         debbugs - Bug was imported from the old bug-tracker, my script will
>                   set this - useful to let developers exclude such bugs if
>                   they don't want to deal with them (most of them are crap
>                   anyways)

Most of the debbugs bugs that were assigned to a particular GNOME 
package are actually _not_ crap, but sure, this looks useufl.
 
>         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

This seems to be a good subsitute for the Inclination field, though
I again have some concerns that the UI for keywords is too cryptic.
 
[...]

> 5.) Products / Components / Versions
> 
>     I think this should be up to the maintainers of a package - ie. each
>     maintainer of a package should create a product and individual components
>     for his package and also decide which version numbers he wants to have.
> 
>     However, we may need a `general' component for each product to make debbugs
>     importing work if the user did not specify a component.

Sounds good. I think we should keep the Product/Component naming;
it works better than Eazel/Helix's Program/Component.

(With the definition of a product being "individual tarball or 
identifiable non-tarball thing such as www.gnome.org")

Regards,
                                        Owen