[Releasing] State of Qt 5.0.0 wk 50 & Meeting minutes: release team meeting 12.12.2012
thiago.macieira at intel.com
Fri Dec 14 00:00:02 CET 2012
On quinta-feira, 13 de dezembro de 2012 20.09.38, Knoll Lars wrote:
> > I see now that the original image by Thiago included pushing and merging
> > between all three branches (somehow I forgot about it…), but I wonder
> > whether that doesn't make things overly complex.
As I said in another email, we're missing a Gerrit feature that would allow us
to re-target a review to a different branch.
The model whereby the devs don't have to care about the release branch has
worked for us in the past. That's what we used in the Perforce days and used
to up until the recent after Gerrit came along. It's a tried model.
> > The release branch is there to optimise for getting the release out. So
> > doesn't it make more sense to ask developers to always push bug fixes to
> > stable, and then pick them into the release branch? That gives full
> > control over that branch. Once we're happy, we release and create the tag
> > on the release branch. Then we merge from stable to release with -s ours
> > (or the opposite… ;-), and by that start the process for the next patch
> > level release.
Do you mean "release team cherry-picks into release"? That's the model we used
The drawback is that the changes of release are all duplicated in stable.
> So with some more thinking and given that fact that
> * we want to limit changes in the release branch to the absolute minimum
> * make the average developers life easier
> * make the release managers life easier
> * limit the amount of required communication with every developer
> * and keep an as simple history as possible in dev and and stable (not
> necessarily in releasing) an approach where the release manager/team picks
> from stable sounds more attractive to me.
Let's do it then for this release. We can look into a different process later,
maybe in a smaller repository or a less critical release.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the Releasing