> On 22 Jan 2021, at 12:39, Oswald Buddenhagen <oswald.buddenha...@gmx.de> > wrote: > > 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.
So things either work, or they need some coordination of the change hat fixes, and the change that bumps the dependencies. Maybe we can simplify that whole thing: * by default, there is no sha1 in the dependencies.yaml files If there is none, assume HEAD of the corresponding branch. With the big breakages for Qt 6 done, this should work for many modules, most of the time. Many of us are already building a large subset of Qt modules daily from HEAD of all of those modules. * only pin the version if the latest HEAD doesn’t work I.e. if current HEAD of qtdeclarative doesn’t pass against new HEAD of qtbase (during the dependency updating round), pin the last-working qtbase revision in qtdeclarative’s dependency.yaml file. I assume we can keep that history of “last sha1 of module that worked” in the CI system rather than in git; if nothing else, we can fall back to whatever is in qt5.git's .gitmodules Once someone has followed up with a patch in qtdeclarative (or qtbase), remove that version pinning again. Eventually, things will be consistent, and .gitmodules gets updated. We won’t have a complete record of all the different qtbase revision against which each qtdeclarative revision tested successfully in the past, but we don't have that that in Qt 5 anyway, and .gitmodules will have equivalent information, at larger intervals. That should reduce the amount of git history noise substantially. >> 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. Storing the state outside of the relevant repository means that we have to stage changes in two repos for things to work again. That makes for a messy orchestration (still less messy than having to get the “proper” .gitmodules updated to a consistent set). > 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. I think it makes sense to recognize that it has become a common practice to document the dependencies of a project in some sort of data file within that project. Wether requirements.txt, package.json, dependencies.yaml, or a “requires” in a conanfile.py. .gitmodules might work for the Qt libraries that are directly under the Qt Project governance, but it won’t help 3rd party libraries. Perhaps there is value in having a more standardised process? Cheers, Volker _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
