[Development] Be careful with duplicate Change-Ids in multiple branches in gerrit

[Liang Qi]

> On 7 May 2019, at 22:13, Oswald Buddenhagen <oswald.buddenhagen at gmx.de> wrote:
> 
> On Tue, May 07, 2019 at 01:52:48PM +0000, Liang Qi wrote:
>> This is a very common issue when I do the integraton work in qt5.
>> 
>> For example, currently we have 5.12->5.13->dev merge order, and the last round 5.13->5.13.0 today. One change(changeA) had been integrated in 5.13, and another change(changeB) with duplicate Change-Id was pushed to 5.13.0 branch with status:open. When I try to merge 5.13 to 5.13.0, the changeB will be picked up by gerrit and be part of the integration, which I found in COIN. Normally that integation will fail, but I am not 100% sure.
>> 
>> I only know the phenomenon, but not the root cause.
>> 
>> If you have a change was merged in lower branch, please try to avoid use duplicate Change-Id in upper branch, at least in the current merge order.
>> 
> please don't give such bad advice.

It’s not advice, more strict than that. This situation had wasted quite some time and energy from me and CI/COIN.

Here is just the latest case which happened yesterday.

When I tried to do the final down merge qt5 5.13->5.13.0 plus the submodule update in 5.13.0, after staged, I got https://codereview.qt-project.org/#/c/260927/ included in the integration in COIN. I need to cancel it and ask the owner or gerrit admin to abandon it. That takes too much time, especially if I tried it during midnight…

I don’t blame the owner of the changes, because they are not familiar with gerrit, especially the situation in Qt Project.

Or perhaps this should be one of the reasons of switching to one dev branch and cherry-pick to other branches development model.

—Liang

> 
> firstly, the issue occurs only if neither change was integrated yet.
> i've yet to see actual evidence of another case.
> and yes, that's a bug in the gerrit CI customization. one can only hope
> that The Upgrade will fix it.
> 
> secondly, if you're doing a cherry-pick which will be followed by a
> merge, _then you're doing it wrong_. most commonly, that will be the
> effect of client-side re-targeting where the original change was not
> abandoned.
> 
>> If you have a change landed in 5.12, and it's ok to have duplicate Change-Id when you cherry-picked it to 5.9, because we don't do merge from 5.9 to 5.12.
>> 
>> Best Regards,
>> Liang
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> https://lists.qt-project.org/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development