Transitioning CI builds of all non-Frameworks from Qt 5.9

[Ben Cooksley]

On Mon, Dec 3, 2018 at 10:31 PM René J.V. Bertin <rjvbertin at gmail.com> wrote:
>
> Hi,
>
> Can't you just configure the CI to use Qt 5.10? I think it's not good to hardcode an "overzealous" (for lack of a better word) Qt version in projects that don't require them AND I think that one should support the current LTS release in as many projects as possible as a general rule of principle.

Not really, because it won't be long before 5.10 is no longer any of
the current mainstream distributions.

>
> There's a reason why those LTS releases exist and that should probably be taken into consideration ESPECIALLY for the KF5 Frameworks (remember why kdelibs4 was split up)!

As mentioned in my mail, this applies to everything but Frameworks.
It doesn't affect Frameworks - which will continue on Qt 5.9 at this stage.

>
> People working only on Linux may not realise it but even Qt 5.9 already dropped support for Mac OS versions that are still widely used.
>
> IMHO, projects that use PIM libraries can decide for themselves how they want to deal with a Qt minimum version bump in those dependencies, while distribution maintainers *could* decide to keep those (and only those) dependencies on an earlier version in order to keep supporting whatever oldest Qt requirement they have (5.9 for my MacPorts packaging). Also, don't of those projects have only optional dependencies on PIM libraries?

For some it's mandatory.

>
> I tend to see a CI as something that tests software on one or a handful of the most common configurations. Anyone not using such a configuration is either on their own or acting as a kind of additional CI.
>
> Bumping the minimum Qt version across the line would decrease the burden on the CI, but probably increase the burden on distributions, or force them to stop following upgrades earlier than justified.
>
> Also:
> > (otherwise we'll end up chasing down build failures for a long time)
>
> How so? If you want to install project B that requires Qt 5.9+ but also uses PIM library A which requires Qt 5.1x you're going to need to install something newer than Qt 5.9 . What kind of build failures we cannot already get ("B requires PIM library A which is not installed") are you expecting?

The CI system has no way of knowing what a project says it requires.
It relies on it's own configuration files to dictate what jobs are
generated, and those jobs in turn determine what platform they're run
on.

What i'm referring to here is the manual process of having to go and
exclude various projects which do use PIM libraries (the CI system
doesn't have a concept of optional, it's either needed or not present
at all). The only way to do this will be by hunting through the
dependency graph, which is easier said than done (because Application
A uses library B which uses library C which in turn uses PIM library
D)

Individual project failures might not seem too bad, apart from the
fact it's me (or one of the handful of people familiar with the CI
system configuration) who will have to update the configuration for
many projects (which will result in either lots of Sysadmin tickets,
or a ton of various people spending time hunting these issues down).

Note that in order for the CI system to operate properly the
"Dependency Build" jobs need to be able to run successfully (otherwise
you'll have missing dependencies when you go to run a build). In most
cases it won't be jobs themselves that fail, it'll be the Dependency
Build jobs - and because these jobs start from scratch (ECM, then up
through Frameworks and so on until every project's dependencies have
been built) it's extremely expensive to keep running these jobs as
they occupy builders for quite a bit of time.

> There could be errors from *other* projects not depending on PIM libraries, but if they intend to support an "older" Qt version that implies rather explicitly that they also intend to address build failures, no?
>

We see those on a semi-regular basis - as those who have seen QtTest
casting issues will be well aware.

>
> R.

Cheers,
Ben