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