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

[Turunen Tuukka]

>________________________________________
>Lähettäjä: releasing-bounces+tuukka.turunen=digia.com at qt-project.org [releasing->bounces+tuukka.turunen=digia.com at qt-project.org] käyttäjän Knoll Lars [Lars.Knoll at digia.com] >Lähetetty: 13. joulukuuta 2012 21:47
>Vastaanottaja: Thiago Macieira
>Cc: <releasing at qt-project.org>
>Aihe: Re: [Releasing] State of Qt 5.0.0 wk 50 & Meeting minutes:        release team meeting 12.12.2012
>
>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?

May not be worth a lot that we agree, but here it goes :)

Our CI / testing infra + talented approvers is an excellent combination for keeping the quality. It allows us to even release directly from the branch as has been seen in 4.8 releases and the Qt 5 releases so far.

However we do benefit from the added flexibility of a brach only available for the release team. It allows to make needed fixes to finalize the release based on test findings without taking an a set of new commits that may break another part. Without these the outcome is what happened to 4.8.4 - weeks after weeks of new candidates. Quite expensive way to handle releases.

But what to do to the release branch after the release? Since all contributions are in stable anyway it is possible to leave that branch to the tag where release is done and close it. In some cases there may even be no changes done except maybe an updated changes file.

I think at least for 5.0.0 the approach is difficult to change and unless someone convinces me otherwise I think this is good for all releases. But naturally I am open for discussion so that we can have the most suitable process here also.

Yours,

            Tuukka