Open Stack

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)