Re: Bugzilla summary

[rms39 columbia edu (Russell Steinthal)]

On 20 Nov 2000 15:48:14 +0100, Martin Baulig wrote:

>Hi guys,
>
>so I'm trying to do some summary on the Bugzilla installation:

First, thanks for your work on the Bugzilla project- other than what 
I mention below, this generally looks good to me.  (Of course, in the 
grand scheme of things GNOME, that's not much. :))

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

Just to verify that my understanding is correct, this means that newly
filed (i.e. UNCONFIRMED or NEW) bugs will be mailed to package-maint?
Or that bugs will be assigned to package-maint?

If that's the case, I think that makes sense...  OTOH, I can't figure 
out what the alternative would be, so it wasn't much of a question. :)

>3.) Fields

[ platforms snipped; looks fine to me]
[ opsys snipped; also, looks fine]

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

It would be useful to have a definition of NORMAL- I know that sounds 
obvious, but I have this feeling that the line between MAJOR/NORMAL 
will be problematic.

Also, so that I can understand this, are these severities initially 
set by the submitter (as with debbugs), or are they defaulted to 
NORMAL until the maintainer (or a Bugzilla account-holder?) changes 
it?

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

I've read through the "life-cycle of a bug" on mozilla.org, but still 
have some questions about how this will translate to GNOME, 
particularly the smaller projects which will use the bug tracker.

If I understand this correctly, I as a maintainer would go to Bugzilla
and search for UNASSIGNED bugs (or lookup the ones I received in
e-mail?) and change them to ASSIGNED (to myself?).  I would also do
the same for NEW, which would be those created by registered Bugzilla
users.  (Other than that, NEW would only exist in projects which had a
QA person other than the maintainer, correct?)


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

I still like NOTGNOME instead of, or at least in addition to, 
INVALID.  It's a much "nicer" way of dealing with legitimate bug 
reports from users who might just be confused.  I also noticed that 
Mozilla uses MOVED to describe distribution-specific Mozilla bugs- do 
we have a proposed policy for those sorts of bugs (probably most 
frequently packaging errors in, for example, the RH7 GNOME packages, 
or Helix GNOME).  Are those NOTGNOME, INVALID, MOVED, etc?

Does REMIND cause an actual machine-generated reminder, or is it just 
a code for maintainer use?  The former would be cool, even if I can't 
think of how I would use it.

I seem to recall that there was some discussion about having an
OBSOLETE or similar code to handle the case where the maintainer
believes the bug to have been fixed in a released version of the
package.  In the absence of such a status/keyword, is the plan simply
to move those bugs directly from UNCONFIRMED to RESOLVED with
resolution FIXED?  And if the user upgrades and the bug remains, it 
is then set to status REOPENED?  (Can the user do this, or do they 
need to file a new bug, which is then linked by the maintainer to a 
REOPENED bug?)

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

This looks good to me, provided it is relatively easy for the
maintainer to add a new version.  Then the release sequence is cvs
tag, make distcheck, post to gnome-announce, update Bugzilla's version
table. 

>6.) Keywords
>        trash   - set the bug to INVALID instead.
>
>    Can we agree on this or do we need more discussion here ?

Looks good to me.

>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 debbug
>s
>    importing work if the user did not specify a component.
>
>    Can we agree on this or do we need more discussion here ?

Looks good.  Just to be clear, this means that, for example, for 
gnome-pim we could have:

Product: gnome-pim
Component: gnomecal
Component: gnomecard
Component: Pilot conduits

>8.) Did I miss something
>
>    In case I forgot something or you'd like to discuss something, add it
>    here ....

I think I raised several new issues above, but the overall framework 
looks good.  I do think it's worth putting a bit of time into writing 
some sort of brief summary for maintainers detailing how this would 
affect them, particularly "small" project teams, as opposed to the 
larger Nautilus, Eazel, gnome-libs, etc. projects.  Particularly if I 
missed something in my questions above. :)

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

Thanks again for your work on this--- you can also assume that
anything I didn't mention above is fine with me.

-Russell
-- 
Russell Steinthal		Columbia Law School, Class of 2002
<rms39 columbia edu>		Columbia College, Class of 1999
<steintr nj org>		UNIX System Administrator, nj.org



_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers