Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches
> Besides all the resource costs to create flatpaks on master builds by default every time, when those are usually not used by anyone anyway. It is important to mention that the pipelines on master usually publish to the nightly repos on cdn.kde.org/flatpak I guess you were not aware of that otherwise I wonder what makes you so confident to know nobody uses it? Cheers, Julius 04.02.2024 19:23:06 Ben Cooksley : > On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau > 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. > >> >> 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. > >> >> 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, how to solve those problems? Did I miss something? >> Could flatpak builds on master branches be made on-demand rather? >> >> Cheers >> Friedrich > > Cheers, > Ben
Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches
On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau 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. > > 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. > > 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, how to solve those problems? Did I miss something? > Could flatpak builds on master branches be made on-demand rather? > Cheers > Friedrich > Cheers, Ben
Re: KDE Review: Skladnik (t.g.f.k.a. KSokoban), returning a KDE1-KDE3 age dino
Am Montag, 29. Januar 2024, 17:11:57 CET schrieb Volker Krause: > On Samstag, 27. Januar 2024 18:22:35 CET Friedrich W. H. Kossebau wrote: > > There are only 2 open checkboxes: > > > > [ ] Passing CI job for Reuse linting > > > > The challenge is that there are a number of old files where the > > contributors might be hard to contact for an explicit license statement > > (CMakeLists.txt, AUTHOR, Messages.sh, ...) > > > > Given the same is true for most other KDE games and then some KDE > > software, > > and Skladnik is actually some (very) old KDE software, just other than its > > KDE games siblings for some time had been excluded from release coverage, > > I > > would ask us to make a pragmatic exception on the requirement here. > > Yes, and doing that is actually existing practice. This point applies > primarily to new code, we obviously can't expect this to get magically fixed > in preexisting code that just moved around or got renamed. Okay, so stroke out that item from the checklist here. Cheers Friedrich
Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches
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", What can be done here to reestablish the old immediate continuous integration workflow? Where new APIs (also from KF) are instantly available? 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. So, how to solve those problems? Did I miss something? Could flatpak builds on master branches be made on-demand rather? Cheers Friedrich
