Release Critical Bugs
Release goals are areas of functionality which developers would like to see as an aim for the next release. They will not hold up the release, but allows the bugs opened for that goal to be raised in severity to 'important'.
The Release Team will help track the status of these (include them in the Release Team status emails etc.). The Release Team will also be more inclined to allow freeze-exceptions for release goal related issues early in freezes.
Please note: a release goal should be:
- SMART (Specific, measurable, attainable, realistic, timely)
- Affect more than just one set of packages (eg: not just a package transition)
- Have an 'advocate', who can track and keep status of progress.
- Be generally consensual
Current release goals
This is a list of all considered, recently completed, rejected or current release goals.
A call for release goals was issued. The proposals, subject to acceptance, are:
Security hardening build flags (carry over from Wheezy)
Completed in Wheezy
Incomplete goals in Wheezy
Completed in Squeeze
These goals were completed in Squeeze.
Proposing a new Release Goal
Proposing a release goal requires at least one advocate and a goal to be worked on. Please also choose one (or more) usertag(s) for bugs that will be filed to achieve this goal.
The proposal workflow is:
Write a status wiki-page under ReleaseGoals/<goal>
send the proposal to <email@example.com>
Responsibilities of an Advocate
An advocate has the following responsibilities:
- Keep the status page up to date.
- Coordinate the work on release goal and ensuring progress.
The Release Team may decide to drop the release goal, if the advocate does not live up to the responsibilities (including failing to ensure progress).
For some goals, the affected packages can be auto-generated from data freely available. This can be used to setup an "auto-progress" tracker.
Help setting up a tracker for usertagged bugs to assist with auto-progress.