> On 3 Feb 2021, at 16:01, Joerg Bornemann <[email protected]> wrote:
> 
> On 2/3/21 11:42 AM, Edward Welbourne wrote:
> 
>>>> The change in question cannot have the Pick-to: 6.1 footer, because
>>>> the branch does not exist. How can I avoid to forget cherry-picking
>>>> that change, once 6.1 is in place?
> 
>>> Yes, that’s a risk with cherry-pick mode.
> 
> That's the confirmation I was looking to provoke. ;-)


It’s a trap!


> The thing is, even with established tools you suggested it's still possible 
> to buy the wrong brand of beer, and just maybe we could improve the process a 
> bit and reduce the risk of having fixes falling through the gaps.


Milk, Joerg.


> And the example can be made worse. Imagine a change with Pick-to: 6.0. You'd 
> end up with a fix in dev and 6.0, but not in 6.1.
> 
>> A fairly straightforward solution would be to downgrade the relevant
>> 'bot's complaint against "this branch does not exist", at least when the
>> branch name matches some "plausible imminent branch-name" heuristic, to a
>> warning rather than a -2.
> 
> And this is very similar to the solution I was going to propose.
> Even better than a heuristic would be to teach sanitary bot the concept of 
> "imminent not-yet-created branch names" and tell him to not complain about 
> those.
> 
> The cherry-pick bot would then be able to run after the "imminent 
> not-yet-created branch" branch creation and pick handfuls of cherries in bulk.

Sounds like a good idea, I’m not a big fan of clever heuristics. We used to do 
“soft branching” for similar reasons, I suppose?

But why not get rid of the gap in the first place, ie instead of having a gap 
between

> - final dependency update sha1s are fixed, full update round started
> - 6.1 branch is created


What stops us from simply creating the branch in the submodules, without caring 
about submodule updates? Does it matter that the fork-point itself provides a 
consistent set? I see how that makes some sense for the qt5.git repo, but not 
for the submodules.

Volker


_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development

Reply via email to