Re: KDE is all about the apps goal
On Tue, Jun 1, 2021 at 2:39 AM Aleix Pol wrote: > > Hi everyone, > As you might have seen in Adam's blog post [1], I'm planning on going > through a set of topics. Before diving into it all, I feel it could be > useful to have a call together before Akademy and see what this > process will look like and which ways we can make it so the creators > in our community get the most of it. > https://szopa.org.pl/kde/2021/05/23/KDE-Goals-May-2021.html > > If you'd like to be part of it, please add yourself into this poll so > we can find the correct time to meet. > https://framadate.org/DcTRSqyekJGUQ1pZ > > If you feel like you prefer discussing the actual topics rather than > the coordination, make sure to join our matrix channel > https://matrix.to/#/!yvNlQHUtUfWrfcFTUU:kde.org?via=kde.org=matrix.org Hi everyone, Let's meet then next Monday at 18h UTC, here. https://meet.kde.org/b/ale-cgt-bbb Looking forward to it! Aleix
KDE is all about the apps goal
Hi everyone, As you might have seen in Adam's blog post [1], I'm planning on going through a set of topics. Before diving into it all, I feel it could be useful to have a call together before Akademy and see what this process will look like and which ways we can make it so the creators in our community get the most of it. https://szopa.org.pl/kde/2021/05/23/KDE-Goals-May-2021.html If you'd like to be part of it, please add yourself into this poll so we can find the correct time to meet. https://framadate.org/DcTRSqyekJGUQ1pZ If you feel like you prefer discussing the actual topics rather than the coordination, make sure to join our matrix channel https://matrix.to/#/!yvNlQHUtUfWrfcFTUU:kde.org?via=kde.org=matrix.org Aleix
Re: All About the Apps Goal
Greetings Jonathan, Le 2021-04-23 à 05:58, Jonathan Riddell a écrit : KDE's All About the Apps Goal hopes to use modern methods of getting our apps to users. I seem not to have been clear about what I mean by that so time to check in and ask again. These days apps (and websites and any software) gets developed by developers who are empowered to deploy them all the way to the user through suitable QA. In the apps of KDE apps that means using app stores (flathub, snap store, appimagehub, microsoft store, fdroid, google play etc) and integrating the packaging for those stores into the apps repos themselves and our release tools. This is a massive change of culture compared to what KDE has largely done until now where the packaging and deployment have been separated into often entirely separated organisations. That does not seem to have served us well, our software has not taken over the world except by other orgaisations who have followed these practices, such as KHTML's derivative now being used by Microsoft Edge. It's not a setup done anywhere outside the Linux distros and KDE has long aspired to move beyond just Linux distros. Our most successful apps have long gone ahead and done this, Krita is now available on the Epic Games store. It seems strange to me not to want to emulate that success. Moving packaging into app repos makes it smoother Recently I made a minimum viable patch for the KDE Gear release tooling to bump up the version numbers where those apps have snapcraft packaging files. However I've been told I shouldn't "overstate the nature of the goal" with an objection to integrating the packaging into the app repositories. https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_205935 <https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_205935> I've little interest in putting lots of apps into app stores without this change of culture where app developers take some responsibility for the end result. It would likely end up with unmaintained apps. So would KDE developers prefer the status quo where our packaging is deliberately separated from our app development? Or can we start with moving, where appropriate for the teams doing the work, to move packaging into the app repos and link the apps with the users? I have trouble understanding the question... would you mind pointing to your previous discussion of this topic? By the way, although this certainly matters to the community and is somewhat topical on this forum, this question is quite technical, and whether or not you ask here, I recommend you ask on a more technical forum (such as the kde-devel mailing list) before. -- Philippe Cloutier http://www.philippecloutier.com
Re: All About the Apps Goal
> That particular patch is confusing as it's claiming to be about giving > developers control, but it's changing a file in the release scripts to > take the control away from the app developers... the exact opposite of > your opening paragraph. > I'm probably understanding it wrong, but then so are others. I read that criticism in the MR discussion, too, and I didn't get it. Here's how I understood the patch and its aims: 1. We have some apps being released by teams/individuals, and some apps that rely on release-team 2. Jonathan wishes to promote the former as a culture because $positive_reasons and $current_trends 3. He believes this requires relevant files to live with the project repository, because it's what the teams generally care to work on - on the face of it, this seems sensible: if you want people to care you move stuff into their area of care 4. Yet we need things to keep working even while we refactor, so the release-team tooling needs to be able to update things in the repositories because of the apps that rely on release-team 5. This sequence of steps therefore starts with this patch Here's what's missing from the conversation: - Consensus-building on $positive_reasons and $current_trends (aka "change management is difficult") - Roadmap planning and roadmap visibility, so intermediary steps make sense in context - Agreeing on implementation strategies and best practices that achieve technical goals, afford flexibility across the range of different things different projects want to do, and so on This particular MR discussion failed largely because we were not collectively ready for a productive one, because the necessary leg work didn't happen. It's a classic case of trouble when initially docking an open source contribution, the good old "you sent your patch to lkml too late and should have asked for input earlier", but part of the responsibility also lies with everyone in the community who saw it elect this goal and didn't (a) spend some time thinking about it and preparing themselves for the discussion and (b) doesn't welcome it when it comes. Best regards, Eike Hein - KDE e.V. vice president, treasurer
Re: All About the Apps Goal
Various responses to this all of which would form interesting discussion points but the common theme seems to be that this isn't wanted or at least not in the way that I'm organising it. So I'll withdraw the proposal and unless anyone wants to take over close the Goal. Jonathan On Fri, 23 Apr 2021 at 10:58, Jonathan Riddell wrote: > KDE's All About the Apps Goal hopes to use modern methods of getting our > apps to users. I seem not to have been clear about what I mean by that so > time to check in and ask again. These days apps (and websites and any > software) gets developed by developers who are empowered to deploy them all > the way to the user through suitable QA. In the apps of KDE apps that > means using app stores (flathub, snap store, appimagehub, microsoft store, > fdroid, google play etc) and integrating the packaging for those stores > into the apps repos themselves and our release tools. > > This is a massive change of culture compared to what KDE has largely done > until now where the packaging and deployment have been separated into often > entirely separated organisations. That does not seem to have served us > well, our software has not taken over the world except by other > orgaisations who have followed these practices, such as KHTML's derivative > now being used by Microsoft Edge. It's not a setup done anywhere outside > the Linux distros and KDE has long aspired to move beyond just Linux > distros. > > Our most successful apps have long gone ahead and done this, Krita is now > available on the Epic Games store. It seems strange to me not to want to > emulate that success. Moving packaging into app repos makes it smoother > > Recently I made a minimum viable patch for the KDE Gear release tooling to > bump up the version numbers where those apps have snapcraft packaging > files. However I've been told I shouldn't "overstate the nature of the > goal" with an objection to integrating the packaging into the app > repositories. > > > https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_205935 > > I've little interest in putting lots of apps into app stores without this > change of culture where app developers take some responsibility for the end > result. It would likely end up with unmaintained apps. > > So would KDE developers prefer the status quo where our packaging is > deliberately separated from our app development? Or can we start with > moving, where appropriate for the teams doing the work, to move packaging > into the app repos and link the apps with the users? > > Jonathan > >
Re: All About the Apps Goal
On Sun, Apr 25, 2021 at 10:04 PM Adriaan de Groot wrote: > On Friday, 23 April 2021 11:58:07 CEST Jonathan Riddell wrote: > > KDE's All About the Apps Goal hopes to use modern methods of getting our > > apps to users. > > Let's reboot this conversation and the discussion in the MR. I'll give it > a > shot: > > > > === > The KDE community selected "All About the Apps" as one of its goals > (https:// > kde.org/goals/). Part of that goal is pushing new packaging formats > (snaps, > flats and appimages). Part of it is improving application metadata -- and > showing that on apps.kde.org. > > When pushing new packaging formats, there's a big difference to > "traditional" > packaging where a source tarball is thrown-over-the-wall to distros, who > then > do their thing with it. New packaging formats (which coincidentally are > all > containerized) put the packaging description into the source repository, > because the "target distro" is known, as part of that new format. > > Effectively, this means that individual apps can opt **in** to a new > format by > adding the snap, or flat, or appimage description files to the source > repository. There are a couple of apps that have done this already. > With regard to Flatpak files, even if an application does add a file to it's repository it still has to register this in the central register at https://invent.kde.org/packaging/flatpak-kde-applications. Those manifests that are not registered in the central register will not be built by the Binary Factory - and Flathub will only pick up manifests that are stored in their repositories from my understanding of how Flathub works. In terms of Appimages, there is no standardised way of producing these at the moment, although this is beginning to take shape in the form of Craft handling this. It should be noted that Craft requires blueprints to be created, which have to be stored in the central repository for those at https://invent.kde.org/packaging/craft-blueprints-kde. Having these in the application repository is not supported. Snaps are the only format under discussion here as far as I am aware. > > For apps that do this, and **also** are part of the Release Service -- er > .. > part of KDE Gear, making use of the release service -- there is a spot of > friction: the release scripts bump versioning information in CMake, set > tags, > make tarballs for "traditional" over-the-wall packaging. The release > scripts > do **not** update the new format information. > > This MR adds one feature to the release script: for apps that have opted > in to > snap (by putting snap-info in the source respository) that use the release > service, the version information is also bumped in the snap-info. (Again, > requires the app to opt-in to snap, and also to opt-in to release service) > === > > > > Is **that** what you're trying to achieve? > > [ade] Cheers, Ben
Re: All About the Apps Goal
On Friday, 23 April 2021 11:58:07 CEST Jonathan Riddell wrote: > KDE's All About the Apps Goal hopes to use modern methods of getting our > apps to users. Let's reboot this conversation and the discussion in the MR. I'll give it a shot: === The KDE community selected "All About the Apps" as one of its goals (https:// kde.org/goals/). Part of that goal is pushing new packaging formats (snaps, flats and appimages). Part of it is improving application metadata -- and showing that on apps.kde.org. When pushing new packaging formats, there's a big difference to "traditional" packaging where a source tarball is thrown-over-the-wall to distros, who then do their thing with it. New packaging formats (which coincidentally are all containerized) put the packaging description into the source repository, because the "target distro" is known, as part of that new format. Effectively, this means that individual apps can opt **in** to a new format by adding the snap, or flat, or appimage description files to the source repository. There are a couple of apps that have done this already. For apps that do this, and **also** are part of the Release Service -- er .. part of KDE Gear, making use of the release service -- there is a spot of friction: the release scripts bump versioning information in CMake, set tags, make tarballs for "traditional" over-the-wall packaging. The release scripts do **not** update the new format information. This MR adds one feature to the release script: for apps that have opted in to snap (by putting snap-info in the source respository) that use the release service, the version information is also bumped in the snap-info. (Again, requires the app to opt-in to snap, and also to opt-in to release service) === Is **that** what you're trying to achieve? [ade] signature.asc Description: This is a digitally signed message part.
Re: All About the Apps Goal
On 2021-04-23 21:04, Ben Cooksley wrote: My personal suggestion would be to pick a few applications and try to work with them to get the tooling up. E.g. Krita, Kate, KWrite and Okular. And try to automate. Don't have the application developers maintain all those variants. It's too much! Maybe it's possible to get craft to a point that it can build for all of those platforms? Maybe it's possible to generate the required files directly with cmake? Give the devs one place to add their dependencies. Give them easy tools they know. If they have to invest looking into how to package for snap they will ask "what do I get over apt?" Craft already looks after Windows and MacOS, and is developing the capability for Android and Appimage (which some projects are already using on the Binary Factory for both). Once the Android and Appimage stuff has matured further we'll likely start requiring projects use Craft rather than permitting bespoke tooling to be used. I would prefer that, too. I use the Craft produced installers for the Windows Store and I hope to better test the Appimage stuff created there, too, for Kate. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: All About the Apps Goal
On Sat, Apr 24, 2021 at 6:29 AM Martin Flöser wrote: > Am Freitag, 23. April 2021, 11:58:07 CEST schrieb Jonathan Riddell: > > > https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_20593 > > 5 > > > > I've little interest in putting lots of apps into app stores without this > > change of culture where app developers take some responsibility for the > end > > result. It would likely end up with unmaintained apps. > > After reading through the merge request I have a feeling that you approach > this in a not optimal way. Change management is difficult. > > Like Nate already wrote it is not clear how that merge request is aiming > the > goal and after being asked to explain you give a non explaining answer > which > certainly did not help. Sorry to say. > > I tried to think about what I would care about if I were maintainer of an > app > and also reflected a little bit on how I thought about packaging while > maintaining KWin. My summary would be: I would not care for snaps. > > To me snap, flatpak, appimage is just the todays rpm, dep, ebuild, > pkgbuild, > etc. The vast amount of different standards makes it impossible to support > them > all which results in not caring for any. > > As an app maintainer I could imagine supporting appimage and/or flatpak. > But > not snap! With the unfree server component and the lack of proper > alternatives > it would go against my FLOSS nature given that there are truly free > alternatives to distribute apps on linux. Similar my motivation to package > for > Windows or Mac as non-free platforms would be extremely low. Especially as > it > would mean investing lots of time to set it up and test it. Maintaining > that > would be lots of work, especially given that I mostly failed at keeping > cmake > dependencies correct. And don't remind me of how often Ben was angry with > me > for requiring new CI requirements without checking before (sorry!). Now it > should be cmake, flatpak, appimage, snap, ms store, apple store, epic > store, > steam store, etc. etc. That's too much for most teams! > Apologies for that Martin. > > Given that I think your approach of changing culture is too strong, which > is > why I mentioned change management in the beginning. > > My personal suggestion would be to pick a few applications and try to work > with them to get the tooling up. E.g. Krita, Kate, KWrite and Okular. And > try > to automate. Don't have the application developers maintain all those > variants. It's too much! Maybe it's possible to get craft to a point that > it > can build for all of those platforms? Maybe it's possible to generate the > required files directly with cmake? Give the devs one place to add their > dependencies. Give them easy tools they know. If they have to invest > looking > into how to package for snap they will ask "what do I get over apt?" > Craft already looks after Windows and MacOS, and is developing the capability for Android and Appimage (which some projects are already using on the Binary Factory for both). Once the Android and Appimage stuff has matured further we'll likely start requiring projects use Craft rather than permitting bespoke tooling to be used. > > Now going back to my armchair, > > Cheers > Martin > > > Cheers, Ben
Re: All About the Apps Goal
Am Freitag, 23. April 2021, 11:58:07 CEST schrieb Jonathan Riddell: > https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_20593 > 5 > > I've little interest in putting lots of apps into app stores without this > change of culture where app developers take some responsibility for the end > result. It would likely end up with unmaintained apps. After reading through the merge request I have a feeling that you approach this in a not optimal way. Change management is difficult. Like Nate already wrote it is not clear how that merge request is aiming the goal and after being asked to explain you give a non explaining answer which certainly did not help. Sorry to say. I tried to think about what I would care about if I were maintainer of an app and also reflected a little bit on how I thought about packaging while maintaining KWin. My summary would be: I would not care for snaps. To me snap, flatpak, appimage is just the todays rpm, dep, ebuild, pkgbuild, etc. The vast amount of different standards makes it impossible to support them all which results in not caring for any. As an app maintainer I could imagine supporting appimage and/or flatpak. But not snap! With the unfree server component and the lack of proper alternatives it would go against my FLOSS nature given that there are truly free alternatives to distribute apps on linux. Similar my motivation to package for Windows or Mac as non-free platforms would be extremely low. Especially as it would mean investing lots of time to set it up and test it. Maintaining that would be lots of work, especially given that I mostly failed at keeping cmake dependencies correct. And don't remind me of how often Ben was angry with me for requiring new CI requirements without checking before (sorry!). Now it should be cmake, flatpak, appimage, snap, ms store, apple store, epic store, steam store, etc. etc. That's too much for most teams! Given that I think your approach of changing culture is too strong, which is why I mentioned change management in the beginning. My personal suggestion would be to pick a few applications and try to work with them to get the tooling up. E.g. Krita, Kate, KWrite and Okular. And try to automate. Don't have the application developers maintain all those variants. It's too much! Maybe it's possible to get craft to a point that it can build for all of those platforms? Maybe it's possible to generate the required files directly with cmake? Give the devs one place to add their dependencies. Give them easy tools they know. If they have to invest looking into how to package for snap they will ask "what do I get over apt?" Now going back to my armchair, Cheers Martin
Re: All About the Apps Goal
Hello Jonathan, I don't think people disagree with the broad outlines of the goal, but it's not obvious to me how the merge request in question supports it. Despite tons of discussion in the MR comments, It's hard for me to understand what the MR does. There is very little explanation of the "what" and the "why". I think maybe that's what's missing, maybe? If it's to enable Snap support in KDE Gear packaging automatically, it would be good to put that in the MR description. And if people's objection to this is unclear maintainership for caretaking the Snap configuration, maybe you can volunteer in your role as goal leader to maintain the Snap configuration stuff? My impression is that you already do this anyway for Neon, so volunteering to do that would mostly be a matter of reassuring people that you'll keep doing what you already do :) Nate On 4/23/21 3:58 AM, Jonathan Riddell wrote: KDE's All About the Apps Goal hopes to use modern methods of getting our apps to users. I seem not to have been clear about what I mean by that so time to check in and ask again. These days apps (and websites and any software) gets developed by developers who are empowered to deploy them all the way to the user through suitable QA. In the apps of KDE apps that means using app stores (flathub, snap store, appimagehub, microsoft store, fdroid, google play etc) and integrating the packaging for those stores into the apps repos themselves and our release tools. This is a massive change of culture compared to what KDE has largely done until now where the packaging and deployment have been separated into often entirely separated organisations. That does not seem to have served us well, our software has not taken over the world except by other orgaisations who have followed these practices, such as KHTML's derivative now being used by Microsoft Edge. It's not a setup done anywhere outside the Linux distros and KDE has long aspired to move beyond just Linux distros. Our most successful apps have long gone ahead and done this, Krita is now available on the Epic Games store. It seems strange to me not to want to emulate that success. Moving packaging into app repos makes it smoother Recently I made a minimum viable patch for the KDE Gear release tooling to bump up the version numbers where those apps have snapcraft packaging files. However I've been told I shouldn't "overstate the nature of the goal" with an objection to integrating the packaging into the app repositories. https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_205935 <https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_205935> I've little interest in putting lots of apps into app stores without this change of culture where app developers take some responsibility for the end result. It would likely end up with unmaintained apps. So would KDE developers prefer the status quo where our packaging is deliberately separated from our app development? Or can we start with moving, where appropriate for the teams doing the work, to move packaging into the app repos and link the apps with the users? Jonathan
Re: All About the Apps Goal
On Fri, Apr 23, 2021 at 11:58 AM Jonathan Riddell wrote: > > KDE's All About the Apps Goal hopes to use modern methods of getting our apps > to users. I seem not to have been clear about what I mean by that so time to > check in and ask again. These days apps (and websites and any software) gets > developed by developers who are empowered to deploy them all the way to the > user through suitable QA. In the apps of KDE apps that means using app > stores (flathub, snap store, appimagehub, microsoft store, fdroid, google > play etc) and integrating the packaging for those stores into the apps repos > themselves and our release tools. > > This is a massive change of culture compared to what KDE has largely done > until now where the packaging and deployment have been separated into often > entirely separated organisations. That does not seem to have served us well, > our software has not taken over the world except by other orgaisations who > have followed these practices, such as KHTML's derivative now being used by > Microsoft Edge. It's not a setup done anywhere outside the Linux distros and > KDE has long aspired to move beyond just Linux distros. > > Our most successful apps have long gone ahead and done this, Krita is now > available on the Epic Games store. It seems strange to me not to want to > emulate that success. Moving packaging into app repos makes it smoother > > Recently I made a minimum viable patch for the KDE Gear release tooling to > bump up the version numbers where those apps have snapcraft packaging files. > However I've been told I shouldn't "overstate the nature of the goal" with an > objection to integrating the packaging into the app repositories. > > https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_205935 > > I've little interest in putting lots of apps into app stores without this > change of culture where app developers take some responsibility for the end > result. It would likely end up with unmaintained apps. > > So would KDE developers prefer the status quo where our packaging is > deliberately separated from our app development? Or can we start with > moving, where appropriate for the teams doing the work, to move packaging > into the app repos and link the apps with the users? Here's a separate ticket that is relevant to the topic: https://phabricator.kde.org/T14380 I think it's important because it tries to address the same as the MR without the actual technical changes in the way. And for what it's worth, I don't think anyone has disagreed with the general sentiment in any of the many places this has been posted. Aleix
Re: All About the Apps Goal
> Recently I made a minimum viable patch for the KDE Gear release tooling to > bump up the version numbers where those apps have snapcraft packaging files. > However I've been told I shouldn't "overstate the nature of the goal" with an > objection to integrating the packaging into the app repositories. A goal does not define implementation. That particular patch is confusing as it's claiming to be about giving developers control, but it's changing a file in the release scripts to take the control away from the app developers... the exact opposite of your opening paragraph. I'm probably understanding it wrong, but then so are others. It's a technical discussion and as such requires an actual technical response. Telling us it's for the goal or appealing to the community with this thread isn't helping deal with the communication issues which are clearly present on that MR to help everyone work out what your masterplan is and how this fits in and actually works towards the end goal. David
Re: All About the Apps Goal
I don't think most people fundamentally object to maintaining packaging for stores, but not everyone is interested in all stores or knows how packaging for all those stores work. Maybe an opt-in process would work, were the application maintainers are encouraged to move the packaging for a specific store to their repository, but only if they are willing to maintain it. Personally for example, I already maintain flatpak recipes in some repositories, but I have little interest in looking into snap. Some automation would be very nice, for example for updating to the latest runtime. That could be done as an automatic commit or just as a script which opens issues in repositories that use outdated runtimes. Jonah OpenPGP_0xA81E075ABEC80A7E.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
All About the Apps Goal
KDE's All About the Apps Goal hopes to use modern methods of getting our apps to users. I seem not to have been clear about what I mean by that so time to check in and ask again. These days apps (and websites and any software) gets developed by developers who are empowered to deploy them all the way to the user through suitable QA. In the apps of KDE apps that means using app stores (flathub, snap store, appimagehub, microsoft store, fdroid, google play etc) and integrating the packaging for those stores into the apps repos themselves and our release tools. This is a massive change of culture compared to what KDE has largely done until now where the packaging and deployment have been separated into often entirely separated organisations. That does not seem to have served us well, our software has not taken over the world except by other orgaisations who have followed these practices, such as KHTML's derivative now being used by Microsoft Edge. It's not a setup done anywhere outside the Linux distros and KDE has long aspired to move beyond just Linux distros. Our most successful apps have long gone ahead and done this, Krita is now available on the Epic Games store. It seems strange to me not to want to emulate that success. Moving packaging into app repos makes it smoother Recently I made a minimum viable patch for the KDE Gear release tooling to bump up the version numbers where those apps have snapcraft packaging files. However I've been told I shouldn't "overstate the nature of the goal" with an objection to integrating the packaging into the app repositories. https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_205935 I've little interest in putting lots of apps into app stores without this change of culture where app developers take some responsibility for the end result. It would likely end up with unmaintained apps. So would KDE developers prefer the status quo where our packaging is deliberately separated from our app development? Or can we start with moving, where appropriate for the teams doing the work, to move packaging into the app repos and link the apps with the users? Jonathan
