[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches
From:       "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date:       2024-02-07 18:48:27
Message-ID: 2390005.cojqenx9y0 () klux
[Download RAW message or body]

Am Sonntag, 4. Februar 2024, 19:22:28 CET schrieb Ben Cooksley:
> On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau <kossebau@kde.org>
> 
> wrote:
> > Hi,
> > 
> > ((cc:kde-frameworks-devel for heads-up, replies please only to
> > kde-core-deve))
> > 
> > I hit the problem that when working on a repo which would like to use
> > latest
> > KF development state to integrate some new KF API just added in
> > cooperation
> > with that very repo wanting to use it, I cannot do so when someone had
> > added a
> > flatpak job on CI to that repo.
> > 
> > Because with such flatpak jobs it seems they are limiting the available KF
> > version not to the current latest one, as expected for continuous
> > integration,
> > 
> > but some older (anywhere documented?) snapshot:
> >     "runtime-version": "6.6-kf6preview",
> 
> Please see https://invent.kde.org/packaging/flatpak-kde-runtime/-/tree/kf6
> for what is in the KF6 preview.

Thanks. So documented by implementation :)

> > What can be done here to reestablish the old immediate continuous
> > integration
> > workflow? Where new APIs (also from KF) are instantly available?
> 
> With Flatpak new APIs were never instantly available - there has always
> been a delay as the Flatpak Runtime uses the most recent released version
> of our software.

I guess this was shadowed by feature development of KF having stalled during 
the Qt5/KF5->Qt6/KG6 porting phase as well as Qt6-based flatpaks jobs only 
activated recently.

> > Right now this is a new extra burden which makes working on new features
> > with
> > KF and apps more complicated. Thus less interesting, and one/I would
> > rather
> > duplicate code in apps to get things done.
> > 
> > Blocking latest KF API from usage also means less testing of that before
> > the
> > initial release.
> > 
> > 
> > Besides all the resource costs to create flatpaks on master builds by
> > default
> > every time, when those are usually not used by anyone anyway.
> 
> Those applications that have a hard dependency on features being added to
> Frameworks are not good candidates for making use of our Continuous
> Delivery systems i'm afraid.
> Both Flatpak and Craft based (Linux Appimages, Android APKs, Windows and
> macOS) CD jobs are best optimised for those applications that rely on the
> stable Frameworks releases.
> 
> There are ways (in .craft.ini) to make newer Frameworks available, but that
> requires that the system recompiles that Framework each time you trigger a
> build and is therefore not recommended.
> 
> Allowing those systems to use the "latest" artifacts of Frameworks would be
> a non-trivial exercise.

So effectively this means:
* KF - no CI on new API with non-KF repos, only KF-internal CI
* KF - no CD, only released versions

Which makes KF a second class product, with lesser testing :(
And less interesting to contribute to, given it gets worse CI/CD care.

One challenge I face myself here are community maintained products, like KDE 
games. I have had some pleasure in spending some time recently (well, a lot 
actually) on them to make sure they all properly move to Q6/KF6 for Gear 
24.02. And would assess myself success here.

Now others have on their own enabled flatpak builds for all the repos on the 
master branch. Because they "could" and it worked at that moment in time with 
the dependencies.

I have some experimental work for the games collected during the Qt6/KF6 port 
work which still needs some brush up & further tuning. It would require 
changes to KF, libkdegames & then all the games.

The current setup which seems to defaults to "binary builds everywhere" makes 
completing that work now something which seems to go against current standards 
and makes me feel uncomfortable, as if I do something wrong/against the plans, 
as I would have to disable all the flatpak builds. (Besides having to do all 
the care/extra work here for an ecosystem I have no business with).

For me this is an extra hurdle to work in KDE. And things are made worse for 
me given I am not convinced by those platforms (besides AppImage perhaps) 
which now are ruling contribution/development here. 

I understand people fancy easy deployment on their favourite platforms, so do 
I. There was a time when also Debian package info was in some KDE projects 
IIRC.
But please think about those who are not into your respective platform, do 
not force them into (supporting) yours.

> > So, how to solve those problems? Did I miss something?
> > Could flatpak builds on master branches be made on-demand rather?

Cheers
Friedrich



[prev in list] [next in list] [prev in thread] [next in thread]