Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches
Am Montag, 5. Februar 2024, 10:58:07 CET schrieb Ben Cooksley: > On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau > > wrote: > > So, how to solve those problems? Did I miss something? > > Could flatpak builds on master branches be made on-demand rather? > > For the record, my rebuild of the 6.6-kf6preview Flatpak Runtime/SDK was > successful, and the failure that kicked this off in KUserFeedback has now > been fixed. > https://invent.kde.org/frameworks/kuserfeedback/-/jobs/1561435 Though what kicked off this very thread was making libkdegames & Co. use current KF development version. And seeing that what used to work without issues in the last years now fail and being impeded, due to the new flatpak support :( Not a flatpak user, so even more sad being side-effected here. Cheers Friedrich
Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches
Am Montag, 5. Februar 2024, 00:15:00 CET schrieb Julius Künzel: > > 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? That was said with the context of at least some people (including me) doing development bursts when there is a time window, pushing multiple times in a row on the same evening (to have each set of change CI-tested on its own, like for platforms one does not have access to). So all the flatpaks in those intermediate builds serve no usage purpose, for developers not into the flatpak ecosystem. Only the last might, if any people actually have a reson to use nightly builds. And was said thinking of applications were there might be no-one interested/ motivated to actually run nightly-builds version for the normal life needs, where you want to rely on stable things to do your actual things in life those are just tools for. And nightly flatpaks might be rather interesting for people test-driving bug fixes occasionally. Or testing translations, though scripty does not trigger flatpak builds, does it? For that some on-demand might be more resource-friendly, instead of defaulting to "always build and force all contributors into supporting it", as I experience that here. Cheers Friedrich
Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches
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 > > 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
Re: Proposal for using gitlab for kdereview process
Long time ago, but perhaps there are still memories... Am Dienstag, 4. Juli 2023, 14:32:59 CET schrieb Jonathan Riddell: > I've gone ahead an updated the Sanity checklist Having come across the checklist items * Passing KDE neon build * App packages in Flatpak, Snap, AppImages and Windows etc as appropriate I tried to understand the background & motivation, but only found this "I've gone ahead an updated" here and the diff from your edit on 4 July 2023: https://community.kde.org/index.php? title=ReleasingSoftware&diff=next&oldid=97120 I assume this was the result of some community discussion. If so I failed to witness and now fail to find it. Could you help me to get more insight into the previous discussion here? Cheers Friedrich
Re: KDE Review: Skladnik (t.g.f.k.a. KSokoban), returning a KDE1-KDE3 age dino
Am Samstag, 27. Januar 2024, 18:22:35 CET schrieb Friedrich W. H. Kossebau: > moving slowly, but moving :) > > Would there be any objections to declare the kde(re)review phase to be > successfully completed now? See below for comments on the checklist. So 10 days passed and no actual objection, so moving it out of kdereview now. Thanks again all for your participation. Next steps planned: * make it qt6.only (local patch ready) * release qt6-only version right after KF 6.0/Gear 24.02.0 * propose for KDE Gear 24.05 inclusion, to rejoin its old game buddies Not ignoring Jonathan's comment on the lack of KDE-side app bundles. I think this needs more discussion, currently searching for any background how this item entered the checklist and by which arguments. Looking at other recent kdereviews, accessibility-inspector passed kdereview without that item fulfilled, got a flatpak recipe later then by a interested contributor. So don't think I am rude here by leaving that open :) I would like to understand this item for now as "Can and has been packaged by some major distris", which can be checked off. Cheers Friedrich
Re: Proposal for using gitlab for kdereview process
https://community.kde.org/Goals/All_about_the_Apps On Wed, Feb 7, 2024 at 11:16 PM Friedrich W. H. Kossebau wrote: > > Long time ago, but perhaps there are still memories... > > Am Dienstag, 4. Juli 2023, 14:32:59 CET schrieb Jonathan Riddell: > > I've gone ahead an updated the Sanity checklist > > Having come across the checklist items > > * Passing KDE neon build > * App packages in Flatpak, Snap, AppImages and Windows etc as appropriate > > I tried to understand the background & motivation, but only found this "I've > gone ahead an updated" here and the diff from your edit on 4 July 2023: > https://community.kde.org/index.php? > title=ReleasingSoftware&diff=next&oldid=97120 > > I assume this was the result of some community discussion. If so I failed to > witness and now fail to find it. Could you help me to get more insight into > the previous discussion here? > > Cheers > Friedrich > >
