Bugzilla summary

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

Hi guys,

so I'm trying to do some summary on the Bugzilla installation:

1.) the beast is installed at

          http://bugzilla.gnome.org/

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

2.) Maintainers

    I think the consensus was to keep the current setup with the
    -maint aliases, but to leave it up to the package maintainers
    to decide whether they want to use them or to have an individual
    contact person.

    Is this ok or does anyone disagree ?

3.) Fields

    There was some discussion on this topic, but we haven't reached
    a consensus yet.

    So I'm posting another draft here.

    ====
    @platforms = (
        "Unspecified",
        "All",
        "DEC Alpha",
        "HP PA-RISC",
        "PowerPC",
        "Intel x86",
        "MIPS",
        "Sun Sparc",
        "Other"
    );

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

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

    and their meanings:

        BLOCKER         - Blocks development and/or testing work
        CRITICAL        - Crashes, loss of data, severe memory leak
        MAJOR           - Major loss of function

        everything below is not release critical:

        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

    @priorities - leave this out

    ====

    Can we agree on this or do we need more discussion here ?

4.) STATUS / RESOLUTION

    Keep it as it with the meaning for STATUS:

        UNCONFIRMED
                All new bugs will get this state until the maintainer sets
                them to NEW or ASSIGNED. People who sign up with Bugzilla
                may directly set them to NEW.
        NEW
                This bug has recently been added to the assignee's list of
                bugs and must be processed. Bugs in this state may be accepted,
                and become ASSIGNED, passed on to someone else, and remain NEW,
                or resolved and marked RESOLVED.
        ASSIGNED
                This bug is not yet resolved, but is assigned to the proper
                person. From here bugs can be given to another person and
                become NEW, or resolved and become RESOLVED.
        REOPENED
                This bug was once resolved, but the resolution was deemed
                incorrect. For example, a WORKSFORME bug is REOPENED when
                more information shows up and the bug is now reproducible.
                From here bugs are either marked ASSIGNED or RESOLVED.

        And for RESOLUTION:

        FIXED
                A fix for this bug is checked into the tree and tested.
        INVALID
                The bug report is invalid for the GNOME Bugtracker. It's
                allowed by policy to set all non-GNOME bugs to INVALID.
        WONTFIX
                The problem described is a bug which will never be fixed.
                This should be reserved for "unfixable" things, otherwise
                use INVALID.
        LATER
                The problem described is a bug which will not be fixed in
                this version of the product.
        REMIND
                The problem described is a bug which will probably not be
                fixed in this version of the product, but might still be.
        DUPLICATE
                The problem is a duplicate of an existing bug. Marking a
                bug duplicate requires the bug# of the duplicating bug and
                will at least put that bug number in the description field.
        WORKSFORME
                All attempts at reproducing this bug were futile, reading
                the code produces no clues as to why this behavior would
                occur. If more information appears later, please re-assign
                the bug, for now, file it.
                (some people suggested adding a new INCOMPLETE, but I think
                 we can use WORKSFORME for this).

    Can we agree on this or do we need more discussion here ?

5.) VERSION

    How do we handle version numbers ?

    I'd suggest that we keep the current system (Bugzilla only allowes a
    pre-defined, fixed set of version numbers which are set by the module
    maintainer) and let people put the full version number into the bug
    report itself. Same for platform/operating system.

    Some people suggested added new fields for the full version number and
    the full operating system, but I think when adding new fields we should
    ask ourselves "will someone ever run a query over this field ?" which is
    obviously wrong for text fields.

    So ideally, we should have bug reports in the form which bug-buddy already
    produces - that the actual bug report starts with a few lines describing
    operating system, version etc.

    Can we agree on this or do we need more discussion here ?

6.) Keywords

    I'd suggest the following list of keywords:

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

             There was a suggestion that we should use this keyword to create
             some "Frequent Problems and how to fix them" page, which I find
             really useful.

    And don't add the following keywords which I proposed earlier:
 
        trash   - set the bug to INVALID instead.

    Can we agree on this or do we need more discussion here ?

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

    Can we agree on this or do we need more discussion here ?

8.) Did I miss something

    In case I forgot something or you'd like to discuss something, add it
    here ....

If this all looks ok, then I'll get Bugzilla with this setup up AQAP and also
make the debbugs import script work with this setup.

This Bugzilla stuff will result in a lot of work for me, so I'd like to ask you
to also tell me if you like this proposal and not only if you disaggree with
some points.

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