[Development] Qt modules, API changes and Qt 6
oswald.buddenhagen at gmx.de
Fri Jan 22 12:39:10 CET 2021
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?
>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.
More information about the Development