r25 - 09 Feb 2006 - 14:31:19 - LisaDusseaultYou are here: OSAF >  Projects Web  >  DevelopmentHome > ReleaseManagementWithBugzilla

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:

  1. Attach your patch to the bug.
  2. Click the "Edit" attachment link
  3. 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 wink

http://bugzilla.osafoundation.org/show_bug.cgi?id=1235

Important Links

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r25 < r24 < r23 < r22 < r21 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.