From kde-devel Thu Feb 08 09:26:52 2024 From: Ben Cooksley Date: Thu, 08 Feb 2024 09:26:52 +0000 To: kde-devel Subject: Re: KDE Gear projects with failing CI (release/24.02) (6 February 2024) Message-Id: X-MARC-Message: https://marc.info/?l=kde-devel&m=170738435105431 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--0000000000001f2fdb0610db6a50" --0000000000001f2fdb0610db6a50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 8, 2024 at 7:17=E2=80=AFAM Friedrich W. H. Kossebau wrote: > Am Mittwoch, 7. Februar 2024, 11:48:57 CET schrieb Ben Cooksley: > > All of the Games Flatpak failures are caused by > > > https://invent.kde.org/games/libkdegames/-/commit/023d1a7b173f9d28453a026= 8e9 > > 1ad1ccb47054b9 I intend to revert that commit in 24 hours unless a > suitable > > explaination can be provided as to why 6.0.0 is actually required. > > > > All that commit has done is cause unnecessary breakage as I can't see > > commits before or after it that justify that bump. > > The purpose of the commits (to libkdegames & libkmahjongg, actually > planned to > do for all of kdegames repos for consistency) has been to test that thing= s > still build everywhere when the major version in the min required KF > version > is changed (5.x to 6.x). > As such major version number change has been the cause for issues in the > past, > as some logic relies on that number sometimes. > So it felt better also tested with KF6 now before the 6.0.0 release > (compare > e.g. the struggles Plasma has had with its major version number-based > logic > recently). > > And while those commits are the trigger, the cause is the design flaw of > the > flatpak jobs on "CI", which now exclude KF from CI & CD on the developmen= t > branches, restrict the use of KF API to released versions. > > To get things rolling again for now, I have reverted the two commits now, > removing the trigger again. > > I hope people find a solution to that challenge > they created here though, because this seems a bit the tail (packaging/ > delivery) wagging with the body (development). > > If things break somewhere over the major version number in the dep > version, I > can say I tried ;) > It's more a reflection of how Flatpak works where applications are built on top of a runtime. In our case, to avoid every single application needing to build every single Framework (and wasting copious amounts of disk space not to mention build CPU time in the process) we place Qt and KDE Frameworks in a runtime so they can be shared. For those curious as to how long it takes to build this runtime (excluding QtWebEngine) see https://invent.kde.org/packaging/flatpak-kde-runtime/-/jobs/1561108 - yes, it takes 2 hours on one of our CI nodes to build. Not something that is practical to build every time you build an application. Craft also has a similar issue as by default it provides the latest released version of dependencies unless that is otherwise explicitly overridden. Using that override though that means it has to build the dependencies you've overridden every single time it performs a build - which is not an efficient use of resources. As such it should be used sparingly, if at all, and only if absolutely needed. In general the expectation is that KDE applications (which is what all these continuous delivery pipelines are aimed at) aim to build as a minimum requirement against the latest released versions of things not in their release unit (such as Frameworks). This also makes it easier for new contributors to "jump in" as they can use the development packages shipped by their distribution rather than needing to build the world first (which is going to put a new contributor off). This is in line with the precedent set over the entire lifetime of our Qt 5 based releases, where Frameworks, Release Service and independently released applications all had independent release schedules and version schemes. I appreciate that major version bumps can cause all sorts of breakage though, i'm expecting some degree of breakage no matter how much we pre-test. > > Cheers > Friedrich > > Cheers, Ben --0000000000001f2fdb0610db6a50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 8, 2024 at 7:17=E2=80=AFAM Fr= iedrich W. H. Kossebau <kossebau@kde= .org> wrote:
Am Mittwoch, 7. Februar 2024, 11:48:57 CET= schrieb Ben Cooksley:
> All of the Games Flatpak failures are caused by
> https://invent.kde.= org/games/libkdegames/-/commit/023d1a7b173f9d28453a0268e9
> 1ad1ccb47054b9 I intend to revert that commit in 24 hours unless a sui= table
> explaination can be provided as to why 6.0.0 is actually required.
>
> All that commit has done is cause unnecessary breakage as I can't = see
> commits before or after it that justify that bump.

The purpose of the commits (to libkdegames & libkmahjongg, actually pla= nned to
do for all of kdegames repos for consistency) has been to test that things =
still build=C2=A0 everywhere when the major version in the min required KF = version
is changed (5.x to 6.x).
As such major version number change has been the cause for issues in the pa= st,
as some logic relies on that number sometimes.
So it felt better also tested with KF6 now before the 6.0.0 release (compar= e
e.g. the struggles Plasma has had with its major version number-based logic=
recently).

And while those commits are the trigger, the cause is the design flaw of th= e
flatpak jobs on "CI", which now exclude KF from CI & CD on th= e development
branches, restrict the use of KF API to released versions.

To get things rolling again for now, I have reverted the two commits now, <= br> removing the trigger again.

I hope people find a solution to that challenge
they created here though, because this seems a bit the tail (packaging/
delivery) wagging with the body (development).

If things break somewhere over the major version number in the dep version,= I
can say I tried ;)

It's more a refl= ection of how Flatpak works where applications are built on top of a runtim= e.=C2=A0

In our case, to avoid every single applic= ation needing to build every single Framework (and wasting copious amounts = of disk space not to mention build CPU time in the process) we place Qt and= KDE Frameworks in a runtime so they can be shared.
For those cur= ious as to how long it takes to build this runtime (excluding QtWebEngine) = see=C2=A0https://invent.kde.org/packaging/flatpak-kde-runtime/-/jobs/1= 561108 - yes, it takes 2 hours on one of our CI nodes to build. Not som= ething that is practical to build every time you build an application.

Craft also has a similar issue as by default it provid= es the latest released version of dependencies unless that is otherwise exp= licitly overridden. Using that override though that means it has to build t= he dependencies you've overridden every single time it performs a build= - which is not an efficient use of resources. As such it should be used sp= aringly, if at all, and only if absolutely needed.

In general the expectation is that KDE applications (which is what all the= se continuous delivery pipelines are aimed at) aim to build as a minimum re= quirement against the latest released versions of things not in their relea= se unit (such as Frameworks).
This also makes it easier for new c= ontributors to "jump in" as they can use the development packages= shipped by their distribution rather than needing to build the world first= (which is going to put a new contributor off).

Th= is is in line with the precedent set over the entire lifetime of our Qt 5 b= ased releases, where Frameworks, Release Service and independently released= applications all had independent release schedules and version schemes.=C2= =A0

I appreciate that major version bumps can caus= e all sorts of breakage though, i'm expecting some degree of breakage n= o matter how much we pre-test.
=C2=A0

Cheers
Friedrich


Cheers,
Ben
=C2=A0=
--0000000000001f2fdb0610db6a50--