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

[Knoll Lars]

On Dec 13, 2012, at 8:47 PM, Knoll Lars <Lars.Knoll at digia.com>
 wrote:

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

Ohh, and before I forget: Let's realise the fact that there will be cherry-picking into the release branch in any case. Simple because changes will get pushed and merged to stable, and we might only see after testing that we actually need that one in the release.

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.

Cheers,
Lars