Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 13/11/14 12:34, 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.

Where is the list of liaisons tracked? Do we have a page similar to
oslo liaisons one?

FYI I'd step in as a formal stable liaison for neutron (unless there
are objections from project PTL; added Kyle to CC).

> 
> 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.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUZdfuAAoJEC5aWaUY1u57eusIALvXfBsEXTY8NQuaE4jQew74
PB7UkdO4lxAd6QYbqt3/0USgw7L9nLQrK8k+PZPJlCEDQkeRMwIfAyWSdpTvSK+H
BnPFoOezI+lu01VT7Gut1uwNd9pKkQLxfR4/bCgDpV0Iy5fHFRWMpbBnKTuZpoh+
y9Wd2t6D1w5refrWIL7tzbwElhnp+Lee0HeaEnYyv3ktF7M6di62iANYrSeRvzDA
EzQsSaUdb9joUQMijgcBtCqLOixUrWpeX+by1yOhbgJ82733V9gbg13hS1jzS9t9
KI2v2u3Xga9F43gCYEtRtbVlsFIZItds60vl7uw4aIEFhzeYm3/mQWamyrGvlrs=
=B5OD
-----END PGP SIGNATURE-----