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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
