|
|
| Line 2: |
Line 2: |
| | = Stable Branch = | | = Stable Branch = |
| | | | |
| − | {{caution|http://docs.openstack.org/project-team-guide/stable-branches.html|Some elements of this page are outdated. In particular, the stable branch policy is now maintained on the project team guide:}} | + | {{caution|http://docs.openstack.org/project-team-guide/stable-branches.html|The stable branch policy is now maintained in the project team guide:}} |
| − | | |
| − | __TOC__
| |
| − | | |
| − | == 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.
| |
| − | | |
| − | === 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 [https://etherpad.openstack.org/p/stable-tracker 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 [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint 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.
| |
| − | | |
| − | [[Category: Horizontal_Team]]
| |
{{{header}}}
