All About the Apps Goal

[Ben Cooksley]

On Sat, Apr 24, 2021 at 6:29 AM Martin Flöser <mgraesslin at kde.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20210424/19d52884/attachment.htm>