[Development] Qt modules, API changes and Qt 6

[Oswald Buddenhagen]

On Thu, Jan 21, 2021 at 04:06:03PM +0000, Volker Hilsheimer 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).
>>>>  [...]
>
>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?
>
yes.

>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?
>
i think so. ^^

> It puts some extra burden on contributors and reviewers (add commit 
> footer with correct sha1,
>
remember that this is only for the commits that explicitly ask for a dep 
update, and they currently do that by modifying the yaml file.

> which will need some extra care when cherry-picking),
>
it would be rather exceptional if such a commit was ever backported, so 
no problem with that, either.

> but it might be possible for Coin to try to move things  forward 
> automatically, just as we do now with the dependency update bot.
>
yes, of course. the mechanism would stay almost identical, only the 
state would be keept in a different (more appropriate) place.

On Thu, Jan 21, 2021 at 04:20:50PM +0000, Tor Arne Vestbø wrote:
>This information does not belong in the commit message.
>
>It belongs in dependencies.yaml,
>
that's just something you're postulating, completely ignoring the points 
made against the very existence of that file.