Open Stack

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)