[Development] Qt modules, API changes and Qt 6

[Volker Hilsheimer]

Reviving this thread as a follow up to the discussion in the “Qt6 repo” thread at

https://lists.qt-project.org/pipermail/development/2021-January/040902.html

> On 17 Sep 2019, at 14:51, Oswald Buddenhagen <oswald.buddenhagen at gmx.de> wrote:
> 
> On Tue, Sep 17, 2019 at 12:39:01PM +0000, Simon Hausmann wrote:
>> Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen:
>>> for example, the information that a build with updated dependencies is required can be stored as an annotation in the commit message (that's exactly what zuul does, afaik), and the incremental propagation of the dependencies can be done in a "shadow" branch of the qt5 repository (technically, that could be a single gerrit change that gets progressively updated).
>>> 
>> Yeah, I was also thinking of using git notes perhaps for storing the information separately. (Doesn't seem to be enabled in our Gerrit? Hopefully I'm wrong :).
>> 
> i don't think using git notes is particularly useful here. the number of affected commits would be rather low, so having an additional commit message footer would not hurt. extracting that information would also be rather easy (git log from the last reference point).

Do I understand your proposals correctly:

Let’s say I make a change in qtdeclarative that depends on a merged change ‘shaA' in qtbase and on ’shaB’ in qtsvg, then I add something like

dependencies: qtbase:shaA qtsvg:shaB

(or whatever syntax we want) to my qtdeclarative commit message?

As for the shadow branch(es) in qt5.git or progressively moving gerrit change(es):

* change shaX in qtbase merges, breaks qtdeclarative
* bot updates shadow-branch's .gitmodules to point at qtbase:shaX; it’s now inconsistent (qtdeclarative doesn’t build or pass tests)
* coin keeps testing qtdeclarative changes against qtbase:shaX~1 (as per upstream .gitmodules), changes that don’t depend on shaX merge
* follow-up change shaY in qtdeclarative is staged, with above annotation asking for qtbase:shaX
* coin tests qtdeclarative with shaY against qtbase:shaX, as per the shadow branch’s .gitmodules. Tests pass, shaY merges, .gitmodules in shadow branch is updated to point at qtdeclarative:shaY

Once the round is complete for all sub modules, the existing git submodule update process updates .gitmodules in the proper branch, and reset the shadow-branch (I suppose).

Was that the idea, Ossi? It puts some extra burden on contributors and reviewers (add commit footer with correct sha1, which will need some extra care when cherry-picking), but it might be possible for Coin to try to move things forward automatically, just as we do now with the dependency update bot.


Volker