What can we expect from our developers

[Ben Cooksley]

On Mon, Jan 29, 2024 at 10:38 PM Sune Vuorela <nospam at vuorela.dk> wrote:

> On 2024-01-29, Jonathan Riddell <jr at jriddell.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20240129/6fa69a14/attachment.htm>