Two truths

Let's face it. No software is bug-free. No software is "feature complete" either, at least from either the developer's perspective, the user's perspective, or both. How these truths relate to our ability to decide if and when to "ship a release" is the focus of this document.

The problems

One problem developers have is a need for a unified place to list all the bugs found in their software. Another is a need for a similar place to list the enhancement and feature requests, perhaps integrated with the first. For this, Mozilla developers use Bugzilla, and it solves these problems quite well.

However, there are other problems still facing us. In the run up to a release, developers need a way to keep track of which bugs must be resolved and which features must be completed before the software will be deemed ready to release. Working within Bugzilla, this particular problem can be solved in different ways.

The past

One side note for clarity: From here on out, a "bug" can refer to both a defect, or a new feature or enhancement.

In the past we have used tracking, or meta bugs to keep track of which bugs must be resolved in order to release. Each "child" bug blocks the "parent" meta bug. Once all blocking bugs are resolved, the release can occur.

This approach, while effective, has the drawback that changes to one bug can cause a cascade of bugspam (mail from Bugzilla) due to all the bug interdependencies. As you can imagine, a tracking bug with tens or hundreds of blocking "child" bugs gets very unwieldy to maintain very quickly.

The present

Thanks to jminta's efforts (and proximity to the relevant Mozilla staff), we will transition from using tracking bugs to using flags. You will now notice a "blocking0.x" flag on all Calendar bugs (where "x" is the version number of a release).

The flag has four states:

• Empty implies the bug does not block the release in question.
• A question mark (?) denotes that the bug has been nominated as a blocker by a Bugzilla user, but that it has not been confirmed as one by the requestee.
• A plus sign (+) denotes that the nomination was approved, and the bug does indeed block the release, as determined by the requestee.
• A minus sign (-) denotes that the nomination was denied, and the bug doesn't block the release, as determined by the requestee.

To summarize: One of the prerequisites for a release to occur is that all the bugs with blocking flags for that release set to "+" must either be resolved, or have their blocking flag removed, and (most likely) be rescheduled (bumped) for the next release.

Audience participation

This also means that you can now nominate a bug to be a blocker!

Examples of blockers are bugs that are in the critical path of the items on that release's roadmap, or bugs that critically hamper usability. These are the only types of bugs you should nominate to block a release!

Nominating a bug to be a blocker because you really really want or need that bug fixed or feature implemented is not appropriate. Votes are the appropriate tool to promote your "favourite" bug. Bounties (cash or other) have also historically been offered to promote work on particular bugs. Better yet, try writing a patch!

The decisions of requestees as to a bug's blocking status are final. Please respect that.

For more information on how to interact with developers via Bugzilla, please see the Bugzilla Etiquette Guide.

To nominate a bug as a blocker, set the "blocking0.x" flag to "?". In addition, include any relevant justification as to why this bug should block the release it in the bug's comments field.