Open Stack

Mark McLoughlin <markmc at redhat.com> writes:

>> To mitigate that, we decided that the group doing stable branch
>> maintenance would be a separate group (i.e. *not* core developers), and
>> we decided that whatever ends up in the stable branch must first land in
>> the master branch.
>
> Well, I recall it a little differently - that both the stable branch
> maint group and the core team members would have +2 privileges on the
> stable branch.

If we discussed that explicitly, I'm afraid it didn't make it into my
notes from the summit.  It wouldn't surprise me if we left the answer to
that question in the bike shed.

> Maybe I just misread James here:
>
>   https://lists.launchpad.net/openstack/msg04751.html
>
>   "only members of the maintainers team or core devs can +/-2"

You read correctly; I took your proposal, translated it into slightly
more formal gerrit terms, and implemented that.  So currently gerrit is
configured so that _either_ core devs or the maintainers team can
approve changes to stable/ branches.

That can be changed, and maintainers can be given exclusive approval
authority over the stable/ branches.

> I also seem to have imagined the core teams being members of the stable
> branch maint team:
>
>   https://launchpad.net/~openstack-stable-maint/+members

Right now it doesn't matter because in gerrit core devs have the same
authority as maintainers.  However, if we make maintainers exclusive
approvers, it might be better for individuals with interests in both to
be individually members of both since the stable branch has extra
behavioral rules.

> But wait! Vish +2ed a stable branch patch yesterday:
>
>   https://review.openstack.org/328
>
> James, help a poor confused soul out here, would you? :)
>
> Right, that makes sense. Only folks that understand the stable branch
> policy[1] should be allowed to +2 on the stable branch.
>
> Basically, a stable branch reviewer should only +2 if:
>
>   - It fixes a significant issue, seen, or potentially seen, by someone
>     during real life use
>
>   - The fix, or equivalent, must be in master already
>
>   - The fix was either a fairly trivial cherry-pick that looks 
>     equally correct for the stable branch, or that the fix has 
>     sufficient technical review (e.g. a +1 from another stable 
>     reviewer if it's fairly straightforward, or one or more +1s from 
>     folks on core it it's really gnarly)
>
>   - If this reviewer proposed the patch originally, another stable
>     branch reviewer should have +1ed it 
>
> All we need is an understanding of the policy and reasonable judgement,
> it's not rocket science. I'd encourage folks to apply to the team for
> membership after reviewing a few patches.

It sounds like the best way to implement this policy is to give
openstack-stable-maint exclusive approval authority on stable branches,
and then make sure people understand those rules when adding them to
that team.  If that's the consensus, I can make the change.

-Jim