[Releasing] State of Qt 5.0.0 wk 50 & Meeting minutes: release team meeting 12.12.2012

[Knoll Lars]

On Dec 14, 2012, at 12:00 AM, Thiago Macieira <thiago.macieira at intel.com>
 wrote:

> 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.

Yes, but I really want to limit it to the release branch which should really only get very few fixes on top of what we merged in from stable.
> 
>>> 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 
> to have.
> 
> The drawback is that the changes of release are all duplicated in stable.

Yes, but if we never merge back from release to stable, the duplication will not be visible in stable at all. So from a development point of view it's mostly invisible. The only drawback would be that you have a different sha1 in release, so finding out whether the change is in a release is a little more tricky. Can be mostly solved by using cherry-pick -x.
> 
>> 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.

Yes, I'm happy to try out things and experiment. But right now I want to get the beast out :)

Cheers,
Lars