openstack team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

Hi everyone,

Since there seems to be some confusion around master vs. stable/diablo
vs. core reviewers, I think it warrants a small thread.

When at the Design Summit we discussed setting up stable branches, I
warned about the risks that setting them up brings for trunk development:

1) Reduce resources affected to trunk development
2) Reduce quality of trunk

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.

So a change goes like this:
* Change is proposed to trunk
* Change is reviewed by core (is it appropriate, well-written, etc)
* Change lands in trunk
* Change is proposed to stable/diablo
* Change is reviewed by stable team (is it relevant for a stable update,
did it land in trunk first)
* Change lands in stable/diablo

This avoids the aforementioned risks, avoids duplicating review efforts
(the two reviews actually check for different things), and keep the
teams separate (so trunk reviews are not slowed down by stable reviews).

Note that this does not prevent core developers that have an interest in
stable/diablo from being in the two teams.

Apparently people in core can easily mistake master for stable/diablo,
and can also +2 stable/diablo changes. In order to avoid mistakes, I
think +2 powers on stable/diablo should be limited to members of the
stable maintenance team (who know their stable review policy).

That should help avoid mistakes (like landing a fix in stable/diablo
that never made it to master), while not preventing individual core devs
from helping in stable reviews.

Regards,

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack