[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