-----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----- _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev