A PTL guide to release management
This guide is intended for OpenStack project technical leads (or candidates for the job) so that they know what is expected of them in order to make successful milestones and releases. it is part of the ReleaseTeam resources.
Availability
The PTL is expected to have sufficient time to dedicate to interaction with the release team. That includes presence at the weekly meetings, but also extra availability on milestone and release weeks. The dates for milestones and releases being known well in advance, please make sure you have sufficient free time on those special weeks. If your job doesn't give you sufficient free time to dedicate to release management, please consider stepping down and let someone with more time on their hands taking over.
Planning and tracking features
Cycle plans
The PTL is expected to produce and maintain general objectives for the development cycle in the cycle plan. This plan contains the blueprints that are expected to be worked on during the cycle. You can find it at blueprints.launchpad.net/PROJECT/CYCLE, for example for Nova in Essex: https://blueprints.launchpad.net/nova/essex.
You can add or remove blueprints in that plan by using the series goal field in the blueprints. Blueprints in the cycle plan should have an indicative milestone set, indicating when in the cycle the feature is expected to be completed. Blueprints in the cycle plan should also have an assignee: the person or development group that has committed to delivering the feature in OpenStack.
Milestone plans
This cycle plan trickles down into milestone plans, for each milestone. Milestone plans appear at: launchpad.net/PROJECT/+milestone/MILESTONE, for example for Nova on essex-3: https://launchpad.net/nova/+milestone/essex-3. When a milestone is in progress, it's important to keep the status of the blueprints accurate: the assignee is supposed to keep the status current, and the PTL to ensure that the status reflects reality. See the blueprints field reference for more details.
Targeted bugs
The PTL can also target bugs that need to be fixed by a specific milestone. Those bugs will appear on the milestone plans, and be reviewed regularly during the weekly meetings.
Milestone delivery week
Milestone-proposed cut (EOD Tuesday)
The deadline for merging new features is the end of the day on the Tuesday of the milestone delivery week. It is the responsibility of the PTL to make it so that at the end of the Tuesday, the milestone plan only contains Implemented or Deferred blueprints. If any blueprint is still open on the Wednesday, that means the PTL requires an (exceptional) deadline extension for that specific blueprint before the milestone-proposed branch is cut. So please make sure that list is reviewed and updated before the end of your Tuesday !
By Tuesday EOD, the targeted bug list should also be cured into a list of release-critical bugs. Bugs that will not be fixed in the next two days (or that have no assignee) should be untargeted (or moved to the next milestone). This bug list becomes a don't release before those bugs are fixed list, so it should be kept as small as possible.
A few hours after EOD, the milestone-proposed branch is cut. This branch is for bugfixes only. Bugs that are fixed in master are set to FixCommitted, bugs that are fixed in milestone-proposed are set to FixReleased. The last build of milestone-proposed becomes the milestone delivery.
Backporting fixes to milestone-proposed (Wednesday/Thursday)
Release-blocking bugs should be:
- targeted to the milestone
merged in master branch (FixCommitted)
- backported to milestone-proposed
merged in milestone-proposed (FixReleased)
Changes proposed to milestone-proposed can be accepted by PTLs and the release manager. The policy for accepting those changes is to doublecheck that the fix is targeted to the milestone, and has landed in master first.
Instructions on backporting changes can be found here.
Milestone day (EOD Thursday)
The buglist on the milestone plan becomes a way to communicate with the release team. If the buglist is all FixReleased, that means the milestone can be released by the release team, starting on Thursday morning. If there are bugs left, they act as a blocker until they are fixed in milestone-proposed, or untargeted. It is the PTL responsibility to make sure that the list accurately represents the "releasability" of their project 
Please plan to be extra available on release cut day, the success of a milestone depends on it.
Release candidates
We use release candidate milestone pages to track the work that's left to do before we can issue the release candidate. All known release blockers must be targeted to the RC milestone. Once that list is empty, we can publish a release candidate (RC1). This release candidate will be used as the release, unless a release-critical bug is found that warrants a release candidate reroll. As time passes, we get more picky about what should trigger a reroll and what should be documented as a known issue. After RC1 the master branch is reopened for development, and only release-critical bugs are backported to the release branch.
The RC bug list should contain all blockers and only blockers. For bugs that would be nice to fix before the final release, we use a tag to identify them (for example, essex-rc-potential).