Re: Bugzilla summary

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

rms39 columbia edu (Russell Steinthal) writes:

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

Well, it'll work as the following:

a.) There'll be a <package>-maint bugzilla gnome org mail alias which will
    go to the maintainer(s) of the package (from the MAINTAINERS file in CVS).
    You can send mail to this address and it'll reach the current maintainers.

    So this has nothing to do with Bugzilla, it's just an address to which
    you can send mail.

b.) Bugzilla lets you specify to whom a newly filed bug will be assigned on
    a per-Component basis.

    It's up to the maintainer of a package to put either himself or this
    alias address there, so he can choose to either use or not to use this
    feature.

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

Yes, that'll make sense - we should then also make NORMAL the default and
keep the rule that MAJOR and above is release critical and that MINOR and
below is not (while NORMAL means the maintainer must look at it and either
set it to MAJOR or MINOR before he can make a release).

Someone (forgot who it was) also suggested renaming TRIVIAL to COSMETIC,
looks like a good idea to me.

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

I think we should set the policy as follows:

a) When you have a Bugzilla account and are in the "GNOME Hackers" group,
   you may set any SEVERITY in a newly submitted bug.

b) Otherwise, you may only set NORMAL or below.

This makes sure that release critical severities are the maintainer's decision
but will allow all developers to set them as well (while everybody must be able
to set lower severities, for instance when someone is explicitly submitting a
wishlist item).

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

More or less, yes.

* when someone submits a new bug report, this'll be either UNCONFIRMED or NEW
  (depending on who reported the bug) - but it'll already by "assigned" to
  you as default component owner.

* You will receive a mail telling you that someone submitted this bug report
  (which will include the full bug report, I'll change the mail sending script
  accordingly).

* You will be able to reply to this mail to contact the person who submitted
  the bug report (not yet, but it will before Bugzilla goes live).

* You will be able to send mail to <bugnumer>@bugzilla.gnome.org and the
  contents will be added to the bug report as additional comments (not yet,
  but it will before Bugzilla goes live).

* Normally, you now change the bug status to ASSIGNED to tell the other
  maintainers of your package that you're willing to work on and fix the bug
  report (so you "accepted" the bug report). However, if you have a small
  package and are the only maintainer, you can also keep it in UNCONFIRMED or
  NEW until you fixed the bug.

  However, it is recommended that you set the status to ASSIGNED if you start
  working on the bug report to avoid that someone else does exactly the same.

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

Ideally, there should be a "send to blah, blah, blub" link to send the bug
to another bug tracker, but the Mozilla people are still working on the XML
import/export stuff, this isn't in the stable release yet.

So I think for v1 of bugzilla.gnome.org we should just close all such bugs
as INVALID and include an appropriate comment so the submitter knows what's
wrong.

For NOTGNOME and INVALID, I think we don't need NOTGNOME, INVALID is much
better for this purpose for two reasons:

a.) INVALID should have the meaning "bug report INVALID for the GNOME bug
    tracker" (which says nothing about the bug itself).

b.) There aren't many bugs which are !NOTGNOME, but INVALID - 99.95% of them
    will be INCOMPLETE, but not INVALID.

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

Not yet agaik, but it'd be easy to have a cron job which queries for all
these and sends remembers.

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

Closing a bug a FIXED is certainly wrong unless you really FIXED it.

The correct thing to do here is to close the bug as INCOMPLETE.

As the submitter of a bug report you are always allowed to edit all
aspects of this bug report no matter which permissions you have in
Bugzilla, it is still "your" bug (means that if you want to drive the
maintainer crazy you can even set its severity to BLOCKER, but I think
we should just assume that most people will behave nicely).

For the email gateway script, we can have some
<bugnumber>-reopen bugzilla gnome org 

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

Well, you can also create "1.2.x" or "1.2" as version number if you want.

> 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

Yes, but also

  Component: general

It is highly deprecated to file any bug reports in this category, but it is
required to make debbugs importing and the email gateway work - there are
just too many people who don't provide a correct Component.

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

Yeah, good idea.

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