Open Stack

OK, since there was no disagreement I pushed the changes to:
https://wiki.openstack.org/wiki/StableBranch

We'll get started setting up project-specific stable-maint teams ASAP.
Cheers,

Thierry Carrez wrote:
> TL;DR:
> Every project should designate a Stable branch liaison.
> 
> Hi everyone,
> 
> Last week at the summit we discussed evolving the governance around
> stable branches, in order to maintain them more efficiently (and
> hopefully for a longer time) in the future.
> 
> The current situation is the following: there is a single
> stable-maint-core review team that reviews all backports for all
> projects, making sure the stable rules are followed. This does not scale
> that well, so we started adding project-specific people to the single
> group, but they (rightfully) only care about one project. Things had to
> change for Kilo. Here is what we came up with:
> 
> 1. We propose that integrated projects with stable branches designate a
> formal "Stable Branch Liaison" (by default, that would be the PTL, but I
> strongly encourage someone specifically interested in stable branches to
> step up). The Stable Branch Liaison is responsible for making sure
> backports are proposed for critical issues in their project, and make
> sure proposed backports are reviewed. They are also the contact point
> for stable branch release managers around point release times.
> 
> 2. We propose to set up project-specific review groups
> ($PROJECT-stable-core) which would be in charge of reviewing backports
> for a given project, following the stable rules. Originally that group
> should be the Stable Branch Liaison + stable-maint-core. The group is
> managed by stable-maint-core, so that we make sure any addition is well
> aware of the Stable Branch rules before they are added. The Stable
> Branch Liaison should suggest names for addition to the group as needed.
> 
> 3. The current stable-maint-core group would be reduced to stable branch
> release managers and other active cross-project stable branch rules
> custodians. We'll remove project-specific people and PTLs that were
> added in the past. The new group would be responsible for granting
> exceptions for all questionable backports raised by $PROJECT-stable-core
> groups, providing backports reviews help everywhere, maintain the stable
> branch rules (and make sure they are respected), and educate proposed
> $PROJECT-stable-core members on the rules.
> 
> 4. Each stable branch (stable/icehouse, stable/juno...) that we
> concurrently support should have a champion. Stable Branch Champions are
> tasked with championing a specific stable branch support, making sure
> the branch stays in good shape and remains usable at all times. They
> monitor periodic jobs failures and enlist the help of others in order to
> fix the branches in case of breakage. They should also raise flags if
> for some reason they are blocked and don't receive enough support, in
> which case early abandon of the branch will be considered. Adam
> Gandelman volunteered to be the stable/juno champion. Ihar Hrachyshka
> (was) volunteered to be the stable/icehouse champion.
> 
> 5. To set expectations right and evolve the meaning of "stable" over
> time to gradually mean more "not changing", we propose to introduce
> support phases for stable branches. During the first 6 months of life of
> a stable branch (Phase I) any significant bug may be backported. During
> the next 6 months of life  of a stable branch (Phase II), only critical
> issues and security fixes may be backported. After that and until end of
> life (Phase III), only security fixes may be backported. That way, at
> any given time, there is only one stable branch in "Phase I" support.
> 
> 6. In order to raise awareness, all stable branch discussions will now
> happen on the -dev list (with prefix [stable]). The
> openstack-stable-maint list is now only used for periodic jobs reports,
> and is otherwise read-only.
> 
> Let us know if you have any comment, otherwise we'll proceed to set
> those new policies up.
> 


-- 
Thierry Carrez (ttx)