Release Management with Bugzilla
This process is similar to the process Mozilla Foundation uses, and as
such, documents a "best practices" process modified for OSAF. *
Nominations
At any time, anyone can nominate a bug to "block" a release. This is done
by setting the '?' (request) state for the approriate "blocking flag" for
the relelease in a bug. For example, to request that a bug should block
the 0.4 release, you would set the '?' state for the "blocking0.4" flag.
Unrequested state would look like this: blocking0.4 [ ].
Additionally, you should state briefly why you think the bug is so important
it should block a release.
After the submitted request, the flag will display who requested it,
in the example below user heikki requested the bug to block 0.4 release.
A request would appear like this: heikki: blocking0.4 [?].
At some point there will be a general call to ask people to nominate
blocking bugs.
Acting on Nominations
There is a bug council that responds
to blocking requests. The team consists of the managers of all the
OSAF working groups, relevant bugs and PMs.
The bug council meets as needed, then weekly in the time before feature
freeze steps into effect. After that, bug council will meet more often as needed,
maybe even on a daily basis, until the release is done.
Everyone is free to attend the bug council meeting, and sometimes the council will invite
specific persons to discuss specific bugs.
The bug council defines a criteria for bugs that should block a release.
The bug council will issue the general call(s) to nominate blockers, including
the advisory on what it considers should be blocking bugs.
The bug council meetings proceed by going through all the nominated bugs, and either
grants or denies the blocking status. In bug flags, granting means the
plus symbol '+' and minus '-' means request denied.
Deferred bugs
The bug council also may defer bugs that should not be fixed in the current release. In each release the bug council should review the active bug list and clean it up, looking for bugs to defer as well as bugs that are now invalid, or otherwise not up-to-date.
Target Milestones
When bug council grants a blocking status to a bug it will also check that the bug
is targeted for an appropriate milestone, and may set the target milestone
if it is not correct.
Priorities
The priority of a bug affects both the order in which bugs are generally tacked, and whether
a bug may get deferred from a release (e.g. to meet a target release date, all bugs except for
P1 and P2 bugs may get deferred as that date approaches).
Priority may not be known by the person who enters a bug. The bug creator should be able to fill in the severity field, but may not know the priority. The priority may be left blank by the bug creator, but if so, it should be filled in during bug assignment/acceptance.
When a person has a bug that has been granted blocking status, it should
be the highest priority work item. If there is a feeling that something
else is more impportant, it should be nominated using the process
described here, and evaluated by the bug council.
When there are several blocker bugs, the priority determines work order.
The bug council may also set the priority field on a bug.
If you have no blocking bugs on your plate, you should see if you can
help someone who has blocking bugs.
If you have no blocking bugs and can not reasonably help someone with
their blocking bugs, you are free to work on other issues.
Feature and Code Freezes
When Feature freeze is in effect, no new features or functionality should be checked in.
When Feature/Code freeze is in effect, you can only check in fixes for bugs
that have been granted blocking status.
During a freeze the bug council will also monitor bugs that it granted blocking
status previously, and may decide to deny a blocking status if it looks
the fix might be too late or too risky.
During freezes code reviews are also required.
Internationalization Freeze
Unused at the moment.
If/when we start to use Internationalization freeze, it means that no changes that will affect localization are allowed. This means that no string changes or image changes or anything that affects localizations will be allowed.
Documentation Freeze
When documentation freeze is in effect, no changes should be checked in. The main purpose of this (short) freeze period just before a release is to allow time for testing the complete release. Only newly found blocker bugs will be fixed, and checkins are by exception only with bug council approval.
Code Review
A code review (or code buddy) system helps us catch mistakes, fix
mistakes faster, and spreads the knowledge around.
After you have gotten the review and check in, you should add a note in
the checkin comment saying who reviewed your code. The format is
r=id
where id is an OSAF username or the full email of a non-OSAF volunteer.
This information helps us to quickly find at least one person who
can fix potential problems with the patch. Also the standard format helps
us track volunteer participation and give credits where they are due.
Bugzilla can help you with code reviews (although it is not mandatory to
use this Bugzilla feature). Here's how:
- Attach your patch to the bug.
- Click the "Edit" attachment link
- In the Flags section request (select '?') a review from a Requestee (write in an email address in the Requestee box)
The requestee should receive an email that you asked for a code review.
The requestee sets the flag to either '+' (granted) or '-' (denied).
If the request is denied, the reviewer must comment why, and what needs
to happen so that they can grant a review for the next patch. It is also
ok to grant a review and suggest or demand minor changes.
You can see your requests by clicking the "My Requests" link in your Bugzilla
footer.
Verifying Bugs
We should verify all bugs that are resolved as FIXED and WORKSFORME after Feature Freeze. Anyone except the person who fixed the bug (or marked it worksforme) can verify a bug. When verifying, mention the build identifier used to verify (or the time of last CVS update), OS and whether it was debug or release version. Check the "Mark bug as VERIFIED" radio button and submit the change to the bug. (Do
not use CLOSED: CLOSED is deprecated.)
Bugzilla Querying
To query Bugzilla for blocking bugs, go to the query page and set the
advanced boolean charts like this (this would find the bugs that have
been nominated to block 0.4 release):
[flag] [is equal to] [blocking0.4?]
Example Bug
Here is a sample bug that has been requested to block 0.4 release and denied. It also has a patch which has been reviewed and denied (without comments, bad reviewer
http://bugzilla.osafoundation.org/show_bug.cgi?id=1235
Important Links