Bugzilla outstanding issues

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

Hi guys,

the Bugzilla installation at

        http://bugzilla.gnome.org/

is now ready and running in RFD (which stands
for "request for discussion") mode :-)

We're in the 40000-49999 number space which I
reserved for testing purposes (the old bugs from
bugs.gnome.org will keep their numbers and run
from 1-39999, new bugs will get >50000).

This means that you should not enter any real
bugs in it, but that you can already play around
with products, components, versions and such.

So what's left to do ?

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.

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 ?

    Are there any other fields we want to change/add ?

3.) Parameters

    Currently we have:

===
@severities = (
        "blocker",
        "critical",
        "major",
        "normal",
        "minor",
        "trivial",
        "enhancement"
);

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

@opsys = (
        "All",
        "AIX",
        "BSDI",
        "HP-UX",
        "IRIX",
        "Linux",
        "FreeBSD",
        "OSF/1",
        "Solaris",
        "SunOS",
        "other"
);

@platforms = (
        "All",
        "DEC",
        "HP",
        "Macintosh",
        "PC",
        "SGI",
        "Sun",
        "Other"
);
===

    Does this make sense or do we want to change anything ?

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

        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)

        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

        discussion - Bug involves changing/adding a feature which needs some
                     discussion or developer is asking for discussion about
                     this bug; this can be quite useful to let other developers
                     quickly search for such "bugs", can also be used for
                     todo lists, feature suggestions etc.

        frequently-reported - This keyword should only be set by the maintainer
            and is useful when we get a very large number of duplicates. In this
            case the maintainer files a bug report with the most info he can get
            about the problem, including a soulution how to fix the problem,
            marks it as "frequently-reported" and marks all other bugs as
            duplicates of this one.

            This is intended mostly for users: they can easily browse the list
            of frequently reported bugs to quickly find the solution of their
            problem if it is already known (I mean, if such a bug is already
            fixed, but some user still has the problem, he can use this keyword
            to search for a solution of his problem). 

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.

That's it, basically.

Let's hope this mail will start a good and constructive discussion about this
stuff so we can move forward ....

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