<div dir="ltr"><div dir="ltr">On Mon, Jan 29, 2024 at 10:38 PM Sune Vuorela <<a href="mailto:nospam@vuorela.dk">nospam@vuorela.dk</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2024-01-29, Jonathan Riddell <<a href="mailto:jr@jriddell.org" target="_blank">jr@jriddell.org</a>> wrote:<br>
> This sort of comment  makes me really sad. The All About the Apps goal,<br>
> which in principle is still ongoing, was an attempt to get KDE developers<br>
> to realise it was important not just to write apps but to actually make<br>
> them available to users, I find it astonishing how we still don't have a<br>
> culture where making our apps available to users is part of our<br>
> responsibility.  There's teams in KDE to help with all these formats.<br>
> Sorry to complain here as the issue is larger than just this one app but<br>
> it's so sad that nobody within KDE wants to help get users using our<br>
> software directly.<br>
<br>
I think this is taking it too far. I think the goal is more about not<br>
getting in the way of people who wants to do this.<br>
<br>
We need to draw a line somewhere about what we expect from *all* of our<br>
developers.<br>
<br>
I don't think that we can expect all of our developers to be great at<br>
 * c++<br>
 * qtquick<br>
 * cmake<br>
 * windows weirdness<br>
 * linux weirdness<br>
 * freebsd weirdness<br>
 * osx weirdness<br>
 * android weirdness<br>
 * packaging flatpaks, appimages, snaps, debs, rpm, .. for linux<br>
 * making osx installers<br>
 * making apk's<br>
 * making windows installers<br>
Beside the domain of the application.<br>
<br>
Yet it is kind of what we are doing with having gating CI setups for<br>
many of these, and adding more. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I'm quite a seasoned developer and I know I can't care for all of that.<br>
I also don't have the time to care for all of these. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
We also don't have extra manpower in the teams that knows about these to<br>
help everywhere.<br>
<br>
We might have a goal about this, but this is just far too many thing to<br>
be good at everything.<br>
<br>
I don't think we should shame individual developers for also realizing<br>
this.<br>
<br>
But where should we draw the line ?<br></blockquote><div><br></div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>From my perspective it is unreasonable to require people to package for every platform/format under the sun. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
/Sune<br>
<br></blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>