Bugzilla Upgrade Notes
Tuesday June 18th, 2002
In a newsgroup posting, Myk Melez says, "Last Monday evening (June 10) I upgraded bugzilla.mozilla.org (b.m.o) to the latest version of Bugzilla plus several enhancements. The upgrade gave us a number of new features and some regressions."
*Please* use a link to groups.google.com, rather than news://...
Not everyone has ready access to a news server.
#2 Re: [OT] USENET links
Tuesday June 18th, 2002 7:57 PM
"*Please* use a link to groups.google.com, rather than news ://..."
"Not everyone has ready access to a news server."
I know, I've been there.
I linked to the article on news.mozilla.org rather than Google Groups because the message hasn't been archived at Google Groups yet. As soon as it is, I'll update the link so that it points to Google Groups' copy.
Until then, here's the full text of the message:
Last Monday evening (June 10) I upgraded bugzilla.mozilla.org (b.m.o) to the latest version of Bugzilla plus several enhancements. The upgrade gave us a number of new features and some regressions.
Most of the new features are already enabled, and the rest will be turned on in the near future. Many of the regressions have already been fixed; I and other members of the Bugzilla community are working on the rest of them.
Major new features include:
* email notification preferences for unconfirmed bugs
You can now turn off email notification of changes to unconfirmed bugs. These preferences override other email notification preferences, so f.e. if you have "added comment" notifications turned on but "unconfirmed" notifications turned off you will *not* receive email when comments are added to an unconfirmed bug.
These preferences are turned on by default, so you do not have to do anything to continue to receive email about unconfirmed bugs. To turn off this email, go to the "edit email preferences" page and uncheck the boxes next to "The bug is in the unconfirmed state":
* redesigned search form
The search form has been redesigned to make it easier to use. The old version of the form will remain the default for a month or two, after which the new version will become the default (but the old version will still be available). Take this time to acquaint yourself with the redesigned form:
* bug aliases
Bug aliases are short, easy-to-remember synonyms for bug numbers that you can use in place of those numbers when adding bugs to dependency lists, finding bugs via the "Find" field in the Bugzilla footer, and in other places. They are particularly useful when given to frequently accessed bugs like meta-bugs for which remembering a name is much easier than remembering a number.
Anyone who can edit bugs in Bugzilla can add an alias to a bug, but you should only add aliases for bugs you reported or which are assigned to you (or with the permission of the reporter/assignee). Once a bug has an alias, anyone can use it to access that bug. The meta-bug tracking post-upgrade issues, for example, has the alias "bmo-regressions".
* request tracker [not yet enabled]
The request tracker is a mechanism for tracking reviews, super-reviews, and approvals. It allows developers to ask reviewers to review their patches and tracks those requests from creation through fulfillment.
Once it's enabled, the Bugzilla community is going to test the request tracker with its own review process, after which mozilla.org staff will decide whether and how to use it in the Mozilla community.
* ability to change your email address [not yet enabled]
Once this feature is enabled, you will be able to change your Bugzilla email address without having to ask the Bugzilla administrators to do it for you.
* additional support for external scripts
buglist.cgi now generates results in RDF format in addition to the default HTML, which is useful for external scripts that programmatically search the database and parse results. Add "format=rdf" to the URL parameters to get data in RDF format.
* lots more bug fixes and minor enhancements
I apply fixes for major regressions the moment they become available. I will fix minor regressions en masse via a short (probably about 15 minutes) period of regularly scheduled downtime once a critical mass of those fixes has built up (probably this week or the next).
For details on regressions and to keep track of post-upgrade issues, see the meta-bug tracking those issues:
#6 EVERYBODY CAN ACCESS A NEWSSERVER FOR FREE! OR NO?
Wednesday June 19th, 2002 1:27 AM
EVERYBODY CAN ACCESS A NEWSSERVER FOR FREE! OR NO?
Google is a HACK to read newsgroups. The LINK should point to the standard location, which is a newsgroup.
Or am I wrong?
There are news servers you could use if 1. you have the time to find one. 2. you are not behind a firewall that blocks News. If only Port 80 is open you can still access google groups but no news server.
My company doesn't feel it is usefull that I spend time on newsgroups and access to them is not possible. (and believe me I have tried) So that leaves the google groups as my only "newssource"
#10 Re: EVERYBODY CAN ACCESS A NEWSSERVER FOR FREE! OR
Wednesday June 19th, 2002 10:30 AM
"Google is a HACK to read newsgroups. The LINK should point to the standard location, which is a newsgroup."
I think linking to Google Groups rather than to news servers is preferable because:
* Not everyone can access a news server, whereas it's a fair assumption that most people who can access MozillaZine can access Google Groups.
* Articles on news servers eventually expire which would break the links. Links to Google Groups will always work (unless Google closes down or something).
Sometimes, as with this article, a posting is not yet archived on Google Groups at the time of publication. In these situations, the best thing is to link to a news server temporarily before updating the link to point to Google Groups.
I looked for a link to "my votes", but couldn't find any - it used to be at the bottom of the bug search results page, but either I'm really being dense, or it has morphed/moved somewhere.
yeah, i could've sworn there used to be a "My Votes" link at
you can still access it from individual bug pages, but i don't recall having to be on an individual bug to review votes. if this isn't the way it used to be, i'd certainly petition to have it added to the main query page.