New status update: The switch to per-project stable review teams is now completed.
People that originally were in the openstack-stable-maint have been split between stable-maint-core (for cross-project stable policy guardians) and $PROJECT-stable-maint (for those specialized in reviewing one project stable branch in particular). If you were a member of openstack-stable-maint and feel like you've been misplaced, don't hesitate to contact me or another stable-maint-core member. Regards, Thierry Carrez wrote: > 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) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev