Bugzilla Status Update 2003-01-02
David Miller
justdave at syndicomm.com
Thu Jan 2 21:35:57 UTC 2003
The following document can be viewed in HTML format with hyperlinks and
tooltips and so forth at
http://www.bugzilla.org/status_updates/2003-01-02.html
Bugzilla Status Update
J. Paul Reed and the Bugzilla Team
Thursday, January 2nd, 2003
Copyright © 2003 The Mozilla Organization.
Introduction
============
The Bugzilla Team is pleased to announce the release of three versions of
Bugzilla today: 2.14.5, 2.16.2, and 2.17.3:
* 2.14.5 is a maintenance release on the 2.14 branch; it contains a
couple of security-related bug fixes.
Note: this is the last 2.14.x release, as the Bugzilla Team has
officially stopped supporting the 2.14 branch.
* 2.16.2 is a maintenance release on the 2.16 branch, containing a
couple of security-related bug fixes. It is recommended that all
production installations upgrade to 2.16.2 to make sure they get
the fixes for these security bugs.
* 2.17.3 is the latest developers' snapshot release from the trunk;
it contains the above security bug fixes as well as tweaks to
features in 2.17.1 (bug and attachment flags, enterprise groups,
etc.). This release is a developers' release and is not generally
intended for production use.
The security bug fixes on the 2.14.x and 2.16.x branches and the trunk all
address the same security bugs. These bugs address cross site scripting
vulnerabilities (which the Bugzilla Team already released an announcement
about on November 26th), and sensitive directory and file permissions. In
all cases, local server compromises aren't possible, but unrestricted
Bugzilla database access is possible.
Unfortunately, none of these release address the Win32 situation which is
still unchanged.
What Happened to 2.17.2?!
=========================
Bugzilla project observers may note that we're releasing a 2.17.3
developers' release without having released a 2.17.2 version.
This was due to an overzealous Bugzilla developer (JayPee) who tagged the
2.17.2 release in CVS before it was quite ready to be released. Because of
the holiday season and a couple of other bugs that were found, the Team
decided to hold the release of 2.17.2 until after the holidays.
But, some astute users noticed the new, incorrect tag and had already
started to pull it from CVS. Therefore, to minimize confusion, and signify
that other patches had been checked into the tree after what had been
dubbed "2.17.2" was tagged, the Team decided to bump the version number to
2.17.3.
Developers (and anyone else) do not want the 2.17.2 "release"; they want
2.17.3.
Check-in Policy Update
======================
As Bugzilla project lead Dave Miller announced in the last status report,
the Bugzilla project has changed its policies regarding check-ins. The new
policy institutes an "approval" process for check-ins and comes as an
addition to our existing review policy.
Previously, to check something into Bugzilla's CVS tree, developers were
only required to get the approval of one or two people on the review team.
That process is now augmented by a requirement of obtaining approval on the
patch from the project lead or a designee before it can be checked in.
Current "designees," if there are any, are noted in the #mozwebtools topic.
This won't amount to a code review, but rather a 'yes' or 'no' on whether
this feature or bugfix in this form at this time is the best course of
action to fulfill Bugzilla's design goals. Approvals are also being used to
coordinate landing patches, so the approval flag generally won't be set
until there's a patch ready to land. If you want to know if a patch you're
working on will likely be given approval for check-in before you expend
effort on it, you can ask on the developers at bugzilla.org mailing list.
Bugzilla developers and reviewers are adjusting to this new policy well,
and it's seemingly serving the Bugzilla project well. The quick release of
another 2.17 developers' snapshot, a mere six weeks after 2.17.1, provides
good evidence of this.
Upcoming Major Features
=======================
The following is a list of major new features the Bugzilla Team is
currently working on. You can find more information, including
implementation/design discussions, proposed landing dates, and status in
the bug reports below. These are also features that the Bugzilla Team would
appreciate help on, so if one of the features below interests you, feel
free to jump into the fray!
* Ability to send email via SMTP instead of relying on a local
installation of sendmail. (Bug 84876)
* PostgreSQL support. (Bug 98304)
* Sybase support. (Bug 173130)
* Ability to add generic customized fields to bugs (Bug 91037)
* Customized resolutions, that allow adding, removing, deactivating
and renaming of resolutions. (Bug 94534)
* Expanding the e-mail preferences to allow watching components,
keywords, etc. (Bug 73665)
* mod_perl support. (Bug 87406)
* New makefile-based installation system (Bug 104660, Bug 105854,
Bug 105855, and Bug 105856)
* Generic charting. Allows users to define arbitrary data sets for
which historical data will be recorded, and then plot those data
sets. Bug 16009.
New Bugzilla Features
=====================
Re-architected Product Groups
-----------------------------
Bug 147275, re-architected product groups, has finally landed. In the
2.17.3 release, the entire mechanism for handling groups has been revised.
It is now possible to exert much more control over how groups and products
are related. In editproducts.cgi, there is now a mechanism to permit you to
edit the "Group Controls" for a product and determine which groups are
applicable, default, and mandatory for each product as well as controlling
entry for each product and being able to set bugs in a product to be
totally read-only unless some group restrictions are met.
The patch author, Joel Peshkin, has noted that all of the possible
scenarios have not been anticipated and this is a new feature, so please Cc
him on all bugs you file against re-architected product groups.
Some examples of advanced uses for the re-architected product groups follow:
* Example: When several products need to be associated with the same
default group (formerly a product group), instead of defining several
groups with the same names as the products and managing memberships in each
group, a single group can be defined to control access and that group can
be set as a "Default" group for all of the products.
* Example: If certain products are never supposed to have a publicly
accessible bug, define a group of all authorized users and set the groups
control for those products to indicate that the group is
Mandatory/Mandatory. This will place bugs in that group without giving the
user any option at all.
* Example: Anyone can enter a security bug. Create a product for
security bugs. Do not restrict entry to the product at all. However, set
the Member/Nonmember permissions to Default/Mandatory for the security
group. This will permit anyone to enter and members of the security group
will be able to override the default group restriction while nonmembers
will be forced to restrict the bug to the security group.
Replication/shadowdb removal
----------------------------
The shadowdb was a readonly copy of Bugzilla's database, which Bugzilla
used for potentially expensive readonly queries, such as from buglist.cgi.
Due to MySQL's table-level locking mechanism, long running queries block
modifications and updates to the database; the shadowdb attempted to
alleviate this bottleneck by creating a second database for these long
running queries to use.
Previously, Bugzilla handled updates from the main database to the copy on
its own by keeping track of every SQL update. These updates were then sent
to the shadow database via a separate process (syncshadowdb). This process
had several bugs and was inefficient.
With the landing of bug 124589, which added MySQL replication support to
Bugzilla, and bug 180870, which removed the old manual syncing code,
Bugzilla 2.17.3 is now able to use the replication facilities provided by
the database to handle these updates. The system is now given the locations
of the two databases, but leaves updating them to an alternative process.
This simplifies the Bugzilla code, and enables further optimizations which
were not possible when Bugzilla needed to capture all of an SQL
UPDATE/INSERT command.
New "always-require-login" Parameter
------------------------------------
This new parameter, added under bug 173761, allows administrators running
commercial or sensitive Bugzilla installations to require users to present
login credentials to access Bugzilla.
Bugzilla is most commonly used for open source projects, where anyone
should be able to search for and view certain types of bugs. But some
entities need to restrict these operations to logged in users; this
parameter allows administrators to require a login on every Bugzilla page,
except for the front page. If users try to access any page without login
credentials (in the form of a valid login cookie) and
"always-require-login" is set, they will be prompted for the information
before being allowed to continue.
Attach and Reassign at Once
---------------------------
When developers attach patches or other attachments (testcases, etc.) to
bugs, they will commonly reassign the bug to themselves shortly thereafter,
since that developer is actively working on that bug. These used to be
distinct steps, which generated two email messages and required Bugzilla
users to attach their patch and then reassign the bug to themselves.
This patch, added as part of bug 116819 allows developers to reassign the
bug to themselves and set the status to accepted during the attachment
creation process. This effectively makes the above process one atomic
operation, reducing bug spam and streamlining a very common process.
Trunk Checkins Since the Last Status Update
===========================================
The following is a list of specific bugs fixed (and their checkin messages)
since the last Bugzilla status report. It is ordered by the checkin date,
as ordered by Bonsai. It includes checkins on the trunk from 11/17/2002 to
01/02/2003. This list was generated by filtering Bonsai's output on that
query.
Bold italic bugs are security-sensitive bugs.
Checkins made without reference to any specific bugs:
* (12/28/02) Release notes update (mattyt)
* (12/21/02) Documentation rebuild (gerv)
* (11/21/02) Post-2.17.1 release documentation corrections (justdave)
Checkin manifest:
(omitted for brevity - please see the online version [link at the top of
this email])
2.16 & 2.14 Branch Checkins Since the Last Status Update
========================================================
The following is a list of specific bugs fixed (and their checkin messages)
since the last Bugzilla status report. It is ordered by the checkin date,
as ordered by Bonsai. It includes checkins on the 2.14 and 2.16 branches
from 11/17/2002 to 01/02/2003. This list was generated by filtering
Bonsai's output on that query (contains both branches).
Bold italic bugs are security-sensitive bugs.
Checkins made without reference to any specific bugs:
* Versions numbers were bumped and release notes updated for both
branches
Checkin manifest:
* Bug 186383 - Checksetup leaves editor backups of localconfig
accessible
* Bug 183188 - collectstats.pl no longer makes data/mining world-
readable
* Bug 179329 - filter quips in "show all the quips" for HTML
Copyright © 2003 The Mozilla Organization.
--
Dave Miller Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/ http://www.bugzilla.org/
More information about the announce
mailing list