On Thu, Jan 28, 2021 at 04:48:31PM +0000, Volker Hilsheimer wrote:
On 22 Jan 2021, at 12:39, Oswald Buddenhagen <oswald.buddenha...@gmx.de> wrote:
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 [t]hat
fixes, and the change that bumps the dependencies.
correct.
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.
that makes things confusing and inconsistent.
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.
the system should be "qt7-safe", though.
* 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.
that's still a second commit in that repo just to remove the pinning.
it's maybe not that much noise, but it's ... weird.
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.
there is no need to resign from a potentially useful feature, though. if
checking out a patchset of a qt5 change can give us that state without
trading off something significant for it, then that's a good thing.
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).
huh? the process doesn't have more stages than the current one, only
that you'd put the info into the commit message of the affected commit
instead of modifying dependencies.yaml in that commit.
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.
that hasn't "become" common practice - _external_ dependencies were
always versioned by the build system (and not some weird parallel
specification ...); that's simply part of configuration management.
.gitmodules might work for the Qt libraries that are directly under the
Qt Project governance,
yes:
On Thu, Jan 14, 2021 at 11:23:32PM +0100, Oswald Buddenhagen wrote:
On Thu, Jan 14, 2021 at 02:08:43PM +0000, Volker Hilsheimer wrote:
Nevertheless, federating the declaration of the dependencies across
modules out to each module is the right idea, I think.
no, it's not. for tightly bound co-evolving packages, the vcs should
provide as much atomicity as reasonably possible.
but it won’t help 3rd party libraries.
correct.
Perhaps there is value in having a more standardised process?
the only "standard" you have is your build system, and whatever meta
layer you build on top of it in the CI system. i did a lot of related
specification work for the latter before i left tqtc, but as soon as i
was gone, the concept was dropped - presumably it was "too hard".
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
