openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #05442
Re: Stable branch reviews
I wonder if we should keep Change ID consistent in stable and master
branches so that if one merged something into master, reviewers
and archaeologists can easily find both related changes in master and all
backports of specific change.
The simple scenario is: push change into master, then cherry-pick it on top
of stable branch(es). Change-Id will be the same, Gerrit will allow one to
find all such backports by clicking on Change-Id.
Kind regards, Yuriy.
On Wed, Nov 9, 2011 at 19:50, Thierry Carrez <thierry@xxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References