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.
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to