flags used by drivers@mozilla.org and what they mean

Skip to first unread message

Asa Dotzler

Dec 20, 2002, 11:33:45 PM12/20/02
There has been some confusion about the usage of flags in
bugzilla.mozilla.org for project management.

Drivers are using two types of flags to manage releases:

The first is a bug flag (which appears on the bug under the Cc: section)
which currently looks like "blocking1.3b[? + -]". You'll see this flag
on all of the Browser and MailNews bugs (and NSPR,NSS,PSM and Directory)
and it is used to nominate a bug to dri...@mozilla.org. We used to do
this with a keyword or a tracking bug. Moving forward this will be done
with bug flags and we'll always get a new flag for the current milestone.

To nominate a bug as blocking a release you set the flag to
"blocking1.3b ?". The "?" is the request that drivers evaluate this bug
as a 1.3 beta blocker. Drivers will mark the bug as "blocking1.3b +" if
they would hold the release for that bug. Drivers will mark the bug
"blocking1.3b -" if they would not hold the release for that bug. A bug
which is marked with a "-" does not indicate that drivers don't want the
fix or that it's somehow not worth fixing. It just indicates that
drivers wouldn't hold up a release for that fix.

The second flag is an attachment flag (or "patch flag"). You'll see the
flag "approval1.0.x[? + -]" (and "approval1.3b[? + -]" as soon as we
enter the freeze for 1.3 beta) in the list of flags in the patch manager
under the "review[? + -]" and "superreview[? + -]" flags. These approval
flags are used to request approval to land a patch during the
driver-managed milestone closure periods and on driver-managed branches.
We used to manage approvals with email but the volume made email

Since we're not in a driver-managed period yet I'll explain the usage of
this flag type for the 1.0.x branch. The same basic idea applies to
trunk milestone lock down periods.

To request approval for a patch that needs to land on the driver-managed
1.0.x branch go to your patch, set the flag to "approval1.0.x ?" and add
a comment in the comment box explaining the importance of landing the
patch, the risk associated with the fix, and the testing that's been
done. If dri...@mozilla.org agree that the patch is important to the
branch/release then the flag will be set to "approval1.0.x +". This is
permission to land the patch. If you get approval please land at the
first _open_tree_ opportunity. Drivers will mark the patch as
"approval1.0.x -" if they do not want the patch to land on the branch at
that time.

Important things to remember about these two flags:

*Requesters use a "?" to make the request/nomination.
*Only dri...@mozilla.org can set the "+" or "-" on these two types of
flags. Others setting the plus or minus risk their bugzilla
*If you've got a patch that's been minused by drivers you can re-request
approval by setting the flag back to "?". Only do this if you're
providing additional information about why that fix should be
accepted for that release.
*Only set the "blocking1.3b ?" flag if you have good reason why that
particular problem should block a release. Ask yourself, "would
I hold up the release for this bug?" before setting the flag.
*It's clear who set the flag so use them carefully. Indiscriminate
marking, like nominating every bug one files, is considered
abuse and like any other bugzilla abuse won't be tolerated.
*A "-" flag doesn't mean that the fix isn't wanted. It just means that
drivers don't think fixing it is critical for this release.

These flags should help us to manage things more easily and should speed
the drivers' response time significantly. There are almost no
restrictions coded into Bugzilla to ensure that these flags are used
appropriately and hopefully we won't need any. Thanks to the Bugzilla
developers for the great new features and thanks to all of you for
taking care in the use of these new tools.


Reply all
Reply to author
0 new messages