Transitioning CI builds of all non-Frameworks from Qt 5.9

[Ben Cooksley]

Hi all,

I've been informed by the PIM developers that they would like to bump
the dependency of the Qt version they use, from Qt 5.9 which it's on
currently, to Qt 5.10.

As a consequence, due to many KDE projects using PIM libraries, their
dependency on Qt will also be effectively bumped. To minimize the
maintenance cost of this bump for the CI system, I would like to bump
everyone up from Qt 5.9 to a newer version of Qt (otherwise we'll end
up chasing down build failures for a long time)

As most distributions have moved on from 5.10, and use Qt 5.11 now
(and will in many cases soon move to Qt 5.12), i'd like to suggest
that instead of going to Qt 5.10, we move straight to 5.11.

Because Frameworks has a two versions prior support policy, it'll
remain on 5.9 for now until it's ready to move up to 5.10 (assuming
5.12 is a usable Qt version)

If nobody has any objections, i'll proceed with this change in around
3 days time.

Cheers,
Ben

[René J.V. Bertin]

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.

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)!

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?

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?
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?


R.

[Ben Cooksley]

On Mon, Dec 3, 2018 at 10:31 PM René J.V. Bertin <[hidden email]> 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

[Elvis Angelaccio]

On 03/12/18 09:46, Ben Cooksley wrote:
> Hi all,

Hi Ben

>
> I've been informed by the PIM developers that they would like to bump
> the dependency of the Qt version they use, from Qt 5.9 which it's on
> currently, to Qt 5.10.
>
> As a consequence, due to many KDE projects using PIM libraries, their
> dependency on Qt will also be effectively bumped. To minimize the
> maintenance cost of this bump for the CI system, I would like to bump
> everyone up from Qt 5.9 to a newer version of Qt (otherwise we'll end
> up chasing down build failures for a long time)

It's not clear if you are suggesting to bump the minimum required Qt
version in each CMakeLists.txt file, or if you are just going to bump
the Qt version used by the CI server.

Could you please clarify? Thanks!

>
> As most distributions have moved on from 5.10, and use Qt 5.11 now
> (and will in many cases soon move to Qt 5.12), i'd like to suggest
> that instead of going to Qt 5.10, we move straight to 5.11.
>
> Because Frameworks has a two versions prior support policy, it'll
> remain on 5.9 for now until it's ready to move up to 5.10 (assuming
> 5.12 is a usable Qt version)
>
> If nobody has any objections, i'll proceed with this change in around
> 3 days time.
>
> Cheers,
> Ben
>

Cheers,
Elvis

[Ben Cooksley]

On Tue, Dec 4, 2018 at 9:45 AM Elvis Angelaccio
<[hidden email]> wrote:
>
>
>
> On 03/12/18 09:46, Ben Cooksley wrote:
> > Hi all,
>
> Hi Ben

Hi Elvis,

>
> >
> > I've been informed by the PIM developers that they would like to bump
> > the dependency of the Qt version they use, from Qt 5.9 which it's on
> > currently, to Qt 5.10.
> >
> > As a consequence, due to many KDE projects using PIM libraries, their
> > dependency on Qt will also be effectively bumped. To minimize the
> > maintenance cost of this bump for the CI system, I would like to bump
> > everyone up from Qt 5.9 to a newer version of Qt (otherwise we'll end
> > up chasing down build failures for a long time)
>
> It's not clear if you are suggesting to bump the minimum required Qt
> version in each CMakeLists.txt file, or if you are just going to bump
> the Qt version used by the CI server.
>
> Could you please clarify? Thanks!

I'll only be bumping the version used by the CI system, the
applications themselves will be left unchanged.

>
> >
> > As most distributions have moved on from 5.10, and use Qt 5.11 now
> > (and will in many cases soon move to Qt 5.12), i'd like to suggest
> > that instead of going to Qt 5.10, we move straight to 5.11.
> >
> > Because Frameworks has a two versions prior support policy, it'll
> > remain on 5.9 for now until it's ready to move up to 5.10 (assuming
> > 5.12 is a usable Qt version)
> >
> > If nobody has any objections, i'll proceed with this change in around
> > 3 days time.
> >
> > Cheers,
> > Ben
> >
>
> Cheers,
> Elvis

Cheers,
Ben