[Development] Qt 6.1 Feature Freeze is in effect now

Volker Hilsheimer volker.hilsheimer at qt.io
Wed Feb 3 17:36:44 CET 2021

> On 3 Feb 2021, at 16:01, Joerg Bornemann <Joerg.Bornemann at qt.io> 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.


More information about the Development mailing list