[Development] Qt modules, API changes and Qt 6

Tor Arne Vestbø Tor.arne.Vestbo at qt.io
Thu Jan 21 17:20:50 CET 2021


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20210121/e502b45c/attachment-0001.html>


More information about the Development mailing list