Re: Bugzilla read to go live?
- From: Owen Taylor <otaylor redhat com>
- To: gnome-hackers gnome org
- Subject: Re: Bugzilla read to go live?
- Date: 09 Dec 2000 22:28:52 -0500
Havoc Pennington <hp redhat com> writes:
> Hi,
>
> Looks good. I played with it and came up with lots of nitpicks
> though. ;-)
>
> I think the text on bugzilla.gnome.org is confusing:
>
> This is Bugzilla: the Mozilla bug system. For more information about
> what Bugzilla is and what it can do, see mozilla.org's bug pages.
> <bugzilla.gnome.org/bugs.jpg> This is where we put in lots of nifty
> words explaining all about bugzilla.
>
> How about "This is the GNOME bug tracker. Choose one of the following
> tasks:" or the like. Then link to mozilla.org somewhere on the bottom
> of the page in fine print.
OK, I changed it to something like this - no fine print though - there
was enough whitespace already without having to impair legibility.
> The same confusing text seems to be on other pages too...
I think you were seeing it in the footer. I've removed it from
there.
> On the bug entry page, "If you think it got it wrong, please tell
> Martin Baulig what it should have been" should probably give Martin's
> email address, or better some bugzilla maintainer alias.
In that place I changed it to say to file a bug report against
the bugzilla.gnome.org product. I also changed the maintainer
email to bugmaster gnome org and set up that alias to
point to Martin and myself.
> The two Access dropdowns seem to provide combinations that don't make
> sense. e.g. if I say "only bugzilla maintainers" and "only gnome
> hackers" do I get the union or the intersection of those groups?
I thikk the wording correctly expresses the fact that it is the
intersection - if you select both, it will only be visible to people
who are both bugzilla maintainers and gnome hackers. How would
you improve it?
> I added a bug: http://bugzilla.gnome.org/show_bug.cgi?id=40011 If I
> try to change status to Assigned then there's an internal server
> error.
Permission problem. Fixed. (If you are working on bugzilla, please
use the cvsup script in the bugzilla user's home directory instead
of updating by hand.)
> http://bugzilla.gnome.org/bug_status.html documents an UNCONFIRMED state that
> doesn't seem to be used (my bug went in as NEW, maybe because I
> assigned it to myself and have canconfirm permissions?).
confirmation is tied up with voting for bugs in a weird way -
if the product has a setting for 'votestoconfirm' than bugs
are entered by default in the UNCONFIRMED state, if not
they are entered in the NEW state.
A bug can be confirmed either because of::
- voting
- Or because someone with canconfirm permissions sets the status
as NEW either when submitting the bug or later.
So, if you set a product to have some number of votes to confirm,
you'd reveal all the bugs I've introduced in the confirmation mechanism.
- Should we remove the UNCONFIRMED state?
- Should we enable it with only manual confirmation?
- Should we expose the voting mechanism? (ugh)
> The help-with-field links on bug pages, such as
> http://bugzilla.gnome.org/show_bug.cgi?id=40011, go to bug_status.cgi
> instead of bug_status.html. e.g. click on Resolution: on the bug page
> and you get a 404.
Red Hat bug tracker accidental carryover. Fixed.
Regards,
Owen
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]