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?

This information does not belong in the commit message.

It belongs in dependencies.yaml, and a git-merge-driver for dependencies.yaml 
should be able to resolve those to a compatible set for each integration, or 
report back if the dependencies can not be satisfied. This would also avoid the 
dance we have have (had) where a submodule update needs to be carefully staged 
with other changes that depend on it or fix something as a result of the update.

Tor Arne
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to