[Development] Qt modules, API changes and Qt 6

[Oswald Buddenhagen]

On Thu, Jan 28, 2021 at 04:48:31PM +0000, Volker Hilsheimer wrote:
> On 22 Jan 2021, at 12:39, Oswald Buddenhagen <oswald.buddenhagen at 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".