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

[Knoll Lars]

On Dec 13, 2012, at 5:20 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:

> On quinta-feira, 13 de dezembro de 2012 16.41.04, Simon Hausmann wrote:
>>> this is already a defeat of the branching concept. repeat after me:
>>> cherry-picks are *bad*.
>> 
>> Can you outline why you believe that they are bad? Is it because the
>> commits  will appear twice in the history, once in stable and once in
>> release?
>> 
>> It seems to me that we're trading developer convenience (push changes to 
>> stable, release dudes selectively pick) against git history hygiene
> 
> Pushing to releases but requiring an approval from the release team was part 
> of the original branching proposal.

The question here is mainly how to merge between stable and release, and how to deal with complexity.

So far my understanding has been that release is fully under the control of the release team. That also implies that a developer doesn't (or shouldn't) need to worry about it too much. We merge from stable to dev, and that's the main complexity the average developer has to worry about. 

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.

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.

That would also keep the git history for dev and stable simpler, as you only have merges between two branches visible there.

Opinions?

Lars