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

Ahumada Sergio Sergio.Ahumada at digia.com
Thu Dec 13 20:28:39 CET 2012


On 12/13/2012 08:09 PM, Thiago Macieira wrote:> On quinta-feira, 13 de dezembro de 2012 18.43.29, Ahumada Sergio wrote:
>> On 12/13/2012 05:20 PM, Thiago Macieira 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.
>>
>> so .. will we have a mixed approach ?
>>
>> push to refs/for/release + cherry-picking ?
> 
> No, why would we need cherry-picking? Do you mean the changes that are already
> in stable?
> 

Yes, that's what I meant. My current understanding was that we were going to *only* cherry-pick from stable to release.

But, it seems that we will follow the initial proposal, so people will need to re-push non-merged changes into release (those that fix a P0/P1, that is) and we need to "something" with those already merged in stable.

refs/for/release is now *open*

> We really need the feature in Gerrit to re-target a patch to a different
> branch...
> 
--
Sergio Ahumada
Release Engineer - Digia, Qt



More information about the Releasing mailing list