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

[Buddenhagen Oswald]

[sorry, OWA reply]

> * we want to limit changes in the release branch to the absolute minimum
>
stage button available only to releases managers - check

> * make the average developers life easier
>
aw. those lazy bastards. ;)

> * make the release managers life easier
>
quite to the contrary. having the contributors actively push towards the release branch eases the work of the release manager.

> * limit the amount of required communication with every developer
>
aw, those deaf bastards. ;)

anyway, so far i had the impression that the P0/P1 process is highly coordinated ...
ok, scratch that. ^^
it's very communication-laden. so it's hard to imagine that somebody aiming at the release would still manage to fail to submit for the right branch.

> * 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.
>
one can argue that a single merge of release back to stable after the release looks easier than *potentially* several forward merges.
but then, cherry-picks (especially if somebody forgets the -x) also *do* make the history more complicated once they get merged back. and we will merge back, because thiago will insist on having the tags being visible on stable and dev.

i can see that even in the best case there will be *some* cherry-picks, but at least i get the satisfaction of slapping people hard for them, because it's not the way it is *supposed* to be. ;)

whatever you decide, *don't* merge -s ours release => stable, especially now that sergio opened release for non-cherry-picks.

________________________________________
From: releasing-bounces+oswald.buddenhagen=digia.com at qt-project.org [releasing-bounces+oswald.buddenhagen=digia.com at qt-project.org] on behalf of Knoll Lars [Lars.Knoll at digia.com]
Sent: Thursday, December 13, 2012 9:09 PM
To: Thiago Macieira
Cc: <releasing at qt-project.org>
Subject: Re: [Releasing] State of Qt 5.0.0 wk 50 & Meeting      minutes:        release team meeting 12.12.2012

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

_______________________________________________
Releasing mailing list
Releasing at qt-project.org
http://lists.qt-project.org/mailman/listinfo/releasing