Re: Bugzilla read to go live?

[Owen Taylor <otaylor redhat com>]

Maciej Stachowiak <mjs eazel com> writes:

> Sorry for being so late to comment on the new bugzilla. Here's a few
> suggestions. They mostly come down to "make it more like the
> Eazel/Helix customized version", but I think some of the changes that
> Darin, Ramiro, Eli and others made are worth having:
> 
> * Add a "bugzilla helper" as the preferred and more prominent way to
>   file new bugs: http://bugzilla.eazel.com/helper.html for an
>   example. This has helped both Mozilla and Nautilus improve bug
>   reporting quality.

This looks good. If you get someone to send me the source 
(assuming there is any but that one HTML file), I'lll look
into integrating it.

> * Add the time estimate field as on bugzilla.eazel.com. Even though
>   you can't do real project management, it's really useful to know
>   about how large a task is when considering things like whether to
>   defer it from a release, whether to grab it from someone else who
>   hasn't touched it in a while, etc.

I think I said this earlier in some mail, though I couldn't find
it last time I looked:

 Priority, Severity, and Time estimate are not 3 independent
 fields. Priority is a computed function of Severity and Time
 estimate - unfortunately one that has to be computed by 
 a person.  
 
 Because of this, including all three gets unwieldy and confusing, since 
 there is duplicated information. There is value in all three,
 but I'm not sure that the marginal increase from adding
 a third is worth the increase in complexity and confusion.

 Which 2 out of the three do I favor? I think priority is definitely
 useful for managing a release; the other two are both less
 important - partly because they both can be conveyed fairly
 well in the text of the bug. 

 But I think we probably need to keep severity - if no other
 reason than it corresponds to the fields for existing bugs
 in debbugs fairly well.  
 
> * Add the inclination field as on buzilla.eazel.com - it helps people
>   who are searching for bugs to grab know which ones people would most
>   like to have taken off their hands.

I hate it! :-) I personally don't think that the inclination field is
useful for the typical open source project where people will be
assigning bugs to themselves, and as such, I think it is just
clutter to include.
 
> * Consider revising the priority and severity fields. The priority
>   fields have no definition at all, let alone one that makes clear
>   what kinds of bugs should be release critical (note that sometimes,
>   even an Enhancement is release-critical). I think the priorities
>   (P0-P6) that we have on bugzilla.eazel.com are more useful, see the
>   definitions here: http://bugzilla.eazel.com/bug_status.html#priority

The priorities do have definitions, I just forgot to put them
onto the page.

What I wrote earlier was:

 Urgent

   This bug requires immediate attention and a new release of the
   software as soon as possible. This will typically be used
   for security problems.

 High

   This should be fixed for the next release of the software.

 Normal

   [ If someone wants a definition for this, they need to give
     it to me. ]   
  
 Low

   This bug would be nice to fix as time permits.

P0-P6 are just confusing, you can't even tell which is more
prioritized. There was mail from Ghee Seng Teo earlier indicating
he thought at least P5 and P6 were not used at all on
the Mozilla project.
 
> * Adding something like the summary reports page on Eazel's bugzilla
>   (http://bugzilla.eazel.com/reports.cgi), this is really useful for
>   seeing who is how doomed, whether people are marking their NEW bugs
>   assigned, how much total work is in the milestone, etc (we'd
>   probably want this customized to let you specify sets of packages
>   you care about for a summary).

That's just a matter of a bit of work to get reports.cgi going
again - its a standard bugzilla feature.
 
> * If this does not already exist, it would be really useful to have a
>   way to set milestones per product.

Hmmmm ... I guess the question is how much you view bugzilla 
as a product management tool. The milestone infrastructure
is there, just removed from the forms.

Milestones perhaps are a little funny for something like GTK+
which has both a stable branch and a HEAD branch. I guess as a
goal we could have it so if you define milestones for a product
you see them on the interface for that product, otherwise
you don't. That might take a few hours of hacking.
 
> * I suggest removing the LATER and REMIND resolutions. I don't think
>   these are useful (according to their definitions they aren't even
>   resolutions really - the right thing to do with bugs that match such
>   criteria is to bump them to a later milestone).

I would agree here - bugs should not be marked resolved if you
want to work on them later. I certainly have no intention of
using them. (And I think having _both_ LATER and REMIND is really
confusing.) What do other people think?
 
> I really love some things about the gnome setup of the query page by
> the way, it's nice to categorize the different types of search fields.

Most of the credit here goes to Dave Lawrence's work on Red Hat 
Bugzilla - I just copied his code / HTML and then shuffled things
about a bit to match our set of fields.
 
> Again, sorry about the lateness of my comments, I have just been way
> too hosed to follow the earlier discussion. Hope these comments are
> useful.

They are definitely useful, though it might have been convenient
to have them earlier. (Or, the changes would have been more
likely to get in earlier - debbugs is so awful I don't want to
sit around forever discussing how to make bugzilla perfect.) 

Regards,
                                        Owen

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