Re: What can we expect from our developers
On 1/2/24 20:04, Jonathan Riddell wrote: My opinion is that KDE project maintainers should aspire to get the projects into the hands of users in a way which makes it a useful tool for the user. That means ensuring the projects are packaged and distributed and updated. That's a big ask of course especially from volunteers but it would be the same of self hosted open source projects on Github or commercial proprietary projects, the difference is we have a community process where if you aren't sure how to achieve something there is probably other people who can help out. When I first took over Umbrello 20 years ago I was surprised that as well as learning C++ and Qt I'd also need to know some artwork and how to make it translatable and follow UI design. Actually making it available to users through app stores is another ask for sure but it's why I'd like that integrated into processes like the KDE Gear release service so projects can offload some of the work. There seems to be minimal interest in this though which I worry keeps KDE projects back. Jonathan Also if you'd like your app build as a Flatpak in CI or on Flathub please don't hesitate to ping us in the Matrix channel: #flatpak:kde.org
Re: What can we expect from our developers
My opinion is that KDE project maintainers should aspire to get the projects into the hands of users in a way which makes it a useful tool for the user. That means ensuring the projects are packaged and distributed and updated. That's a big ask of course especially from volunteers but it would be the same of self hosted open source projects on Github or commercial proprietary projects, the difference is we have a community process where if you aren't sure how to achieve something there is probably other people who can help out. When I first took over Umbrello 20 years ago I was surprised that as well as learning C++ and Qt I'd also need to know some artwork and how to make it translatable and follow UI design. Actually making it available to users through app stores is another ask for sure but it's why I'd like that integrated into processes like the KDE Gear release service so projects can offload some of the work. There seems to be minimal interest in this though which I worry keeps KDE projects back. Jonathan
Re: What can we expect from our developers
On Dienstag, 30. Januar 2024 22:05:16 CET Ingo Klöcker wrote: > On Dienstag, 30. Januar 2024 21:47:51 CET Friedrich W. H. Kossebau wrote: > > I think I understand where you are coming from, that all the work on > > software done here makes the more sense the more users there are. IMHO > > though reaching more users of Free Software should be done in ways and for > > platforms which are not giving more power to monopolists or those which > > seem set to become some. Flatpak, Snap, Windows, macOS... they are all > > about binaries. There is no simple way, part of the concept, to get the > > sources, patch something to one's likes and then regenerate the very same > > package, just as custom one. Or is there? > > Yes, there is. They can simply use our infrastructure for this. We are doing > much more than just providing the sources. We provide the fully functional > CI/ CD machinery for building custom versions (minus digital signatures > which we reserve for our official release artifacts). That, and for Flatpak specifically this is very much part of the concept/ toolchain even. I find the support/integration in e.g. GNOME Builder for this particular impressive, I don't think many other packaging formats/toolchains are getting anywhere close in terms of "time to modified app running locally", with no need to deal with dependencies manually, and with no risk of impacting the rest of your system. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: What can we expect from our developers
On Dienstag, 30. Januar 2024 21:47:51 CET Friedrich W. H. Kossebau wrote: > I think I understand where you are coming from, that all the work on > software done here makes the more sense the more users there are. IMHO > though reaching more users of Free Software should be done in ways and for > platforms which are not giving more power to monopolists or those which > seem set to become some. Flatpak, Snap, Windows, macOS... they are all > about binaries. There is no simple way, part of the concept, to get the > sources, patch something to one's likes and then regenerate the very same > package, just as custom one. Or is there? Yes, there is. They can simply use our infrastructure for this. We are doing much more than just providing the sources. We provide the fully functional CI/ CD machinery for building custom versions (minus digital signatures which we reserve for our official release artifacts). Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: What can we expect from our developers
Am Montag, 29. Januar 2024, 10:38:11 CET schrieb Sune Vuorela: > On 2024-01-29, Jonathan Riddell wrote: > > This sort of comment makes me really sad. The All About the Apps goal, > > which in principle is still ongoing, was an attempt to get KDE developers > > to realise it was important not just to write apps but to actually make > > them available to users, I find it astonishing how we still don't have a > > culture where making our apps available to users is part of our > > responsibility. There's teams in KDE to help with all these formats. > > Sorry to complain here as the issue is larger than just this one app but > > it's so sad that nobody within KDE wants to help get users using our > > software directly. > > I think this is taking it too far. I think the goal is more about not > getting in the way of people who wants to do this. What Sune says. I am sorry to be among those saddening you by not living up to your hopes. To share you my perspective, for me almost all of these platforms are the same challenge as I face with localizations: I do not speak the "language" or live the "culture", thus cannot do anything effectively there to properly integrate the artifact generated from the sources written. I have only x leisure time to spend, so I spend it on the things I feel I understand & can responsibly create proper results at. And leave it to the domain experts to do what is needed or useful in their field. Like translators, to localize things for a given locale. Or packagers, to generate the binary blobs which work on a given platform. Or sysadmin, to maintain and run the environment which only enables us to work on software here in this place. Next, making apps available to users on their platforms also means supporting them there. Which again needs proper clue (and access to those platforms) to be effective with the given resources one can take from ones capabilities. I am sharing the result of my developing efforts here as sources, by a very grateful license which also emphasizes the sources, not some platform specific binary blob. To allow those interested to make use of the product with their platforms of choices/realities, adapting and enhancing it where they want to their desires. Similar to making the software localizable, so those interested can make it fit their local culture. Likewise visual styles or other configuration options. Additionally: I think I understand where you are coming from, that all the work on software done here makes the more sense the more users there are. IMHO though reaching more users of Free Software should be done in ways and for platforms which are not giving more power to monopolists or those which seem set to become some. Flatpak, Snap, Windows, macOS... they are all about binaries. There is no simple way, part of the concept, to get the sources, patch something to one's likes and then regenerate the very same package, just as custom one. Or is there? Which makes the apps basically "free beer apps" for those users. Not the business I am here for. But again, packaging is not my domain anyway. Cheers Friedrich
Re: What can we expect from our developers
On Mon, Jan 29, 2024 at 10:38 PM Sune Vuorela wrote: > On 2024-01-29, Jonathan Riddell wrote: > > This sort of comment makes me really sad. The All About the Apps goal, > > which in principle is still ongoing, was an attempt to get KDE developers > > to realise it was important not just to write apps but to actually make > > them available to users, I find it astonishing how we still don't have a > > culture where making our apps available to users is part of our > > responsibility. There's teams in KDE to help with all these formats. > > Sorry to complain here as the issue is larger than just this one app but > > it's so sad that nobody within KDE wants to help get users using our > > software directly. > > I think this is taking it too far. I think the goal is more about not > getting in the way of people who wants to do this. > > We need to draw a line somewhere about what we expect from *all* of our > developers. > > I don't think that we can expect all of our developers to be great at > * c++ > * qtquick > * cmake > * windows weirdness > * linux weirdness > * freebsd weirdness > * osx weirdness > * android weirdness > * packaging flatpaks, appimages, snaps, debs, rpm, .. for linux > * making osx installers > * making apk's > * making windows installers > Beside the domain of the application. > > Yet it is kind of what we are doing with having gating CI setups for > many of these, and adding more. > I'm quite a seasoned developer and I know I can't care for all of that. > I also don't have the time to care for all of these. > We also don't have extra manpower in the teams that knows about these to > help everywhere. > > We might have a goal about this, but this is just far too many thing to > be good at everything. > > I don't think we should shame individual developers for also realizing > this. > > But where should we draw the line ? > For the various platform weirdnesses, it really comes down to whether you as the team behind an application (even if that team is one person) are looking to support said platform in some way or another. If there is interest in supporting the application - then you'll need to resolve those weirdnesses for that platform - and can then usually build on that to get it packaged. If you are not, then it shouldn't be there. This is part of the reason why the KDE on Windows project transitioned to providing single installers for a specific application (using what is now called Craft) rather than the package manager type approach taken in the KDE 4 era. You can't just compile everything and hope the user experience will be good, as tuning does need to be done to deliver an optimised installer and to ensure that everything works properly (such as the application being able to find the various assets it needs such as icons, QML files, etc). The only exception to the above would be libraries or other shared components where other people depend on you (where even if you as a specific library aren't too concerned about say Android support, there may still be applications that use you that do care so you should continue to have CI for those platforms). >From my perspective it is unreasonable to require people to package for every platform/format under the sun. That comes with a caveat though - that if you are looking to get visibility for your software on other platforms (say Android and Windows) then you would need to look into the requisite packaging work for that platform (as it is unreasonable to expect the team that maintains Craft, etc to do that work). The same would apply for nightly Linux builds, where you'd be expected to look into the Appimage or Flatpak packaging. That isn't to say they wouldn't provide pointers or advice, but a degree of investment from your side in making it work seems to be a reasonable expectation. The good news here though is that Craft packaging is pretty good at being shared between platforms - so you can often get things like Windows and Linux Appimages for the price of one piece of work. In terms of the original goal that Jonathan was mentioning - my interpretation of it was to make this as pain free as possible to achieve. Something that we have mostly done through Gitlab CD systems, which have the ability to turn out Flatpak bundles, Linux Appimages, Android APKs and Windows installers and portable archives. > > /Sune > > Cheers, Ben
