Revision as of 10:53, 2 March 2016

Stable Branch

{{{header}}}

{{{body}}}

Team organization

Project-specific teams

Each project with a stable branch will have a specific $PROJECT-stable-maint team, which would be in charge of reviewing backports for a given project, following the stable branch policy. Originally that group should be the project Stable Branch Cross-Project Liaison + the stable-maint-core team. Those groups are managed by stable-maint-core, names are added after the suggestion of the Stable Branch CPL.

Stable release managers

The stable-maint and release teams work together to publish point releases from the stable branch. See StableBranchRelease for details about how these releases are prepared.

One week before the planned point release, stable release manager will announce that stable branch is frozen to allow testing before the release. Freeze exceptions can be proposed on openstack-dev list with [stable] tag in subject where stable-maint team will try to reach consensus.

When new OpenStack version is released it becomes "Current stable release, security-supported"" and previous version "Security-supported". "Current stable release" is the primary target for backports of bugfixes by the stable-maint team, other active branches may receive bugfix backports. "Security-supported" releases are target for the security fixes by the VMT OpenStack Havana stable release will reach EOL at Juno (N+2) milestone-3 and stable releases starting from Icehouse will reach EOL 15 months after their release (approximately N+3 milestone-2).

Stable-Maint-Core team

The stable-maint-core team is responsible for the enforcement of the Stable Branch policy. It is composed of Stable release managers, Stable branch champions and other cross-project stable branch custodians. It will be granting exceptions for all questionable backports raised by $PROJECT-stable-maint groups, providing backports reviews help everywhere, maintaining the stable branch policy (and make sure its rules are respected), educating proposed $PROJECT-stable-maint members on those rules and adding them to $PROJECT-stable-maint teams.

Joining the Team

We're really keen to add more folks to the stable-maint teams to help out with reviews.

All you really need is some time and the ability to apply the "safe source of high impact fixes" and "must be fixed on master first" policies. It mostly comes down to having a good sense of the risk vs benefit of applying a backport to the branch.

If you'd like to join the team, you can start by simply [+-]1ing stable branch reviews. It's best if you can add some brief thoughts to your review on why you think the fix is suitable for stable so that we know how you're applying the policy.

Same as in other OpenStack core teams, stable-maint membership will be periodically reviewed and inactive members removed.

Gate Status

Keeping the stable branches in good health in an ongoing effort. To see what bugs are currently causing gate failures and preventing code from merging into stable branches, please see the stable tracker etherpad, where we will track current bugs and in-flight fixes.

Scheduled test runs occur daily for each project's stable branch. If failures crop up, the bot will email the openstack-stable-maint mailing list . It is best to react quickly to these and get them resolved ASAP to prevent them from piling up. Please subscribe if you're interested in helping out.