<div dir="ltr"><div dir="ltr">On Sat, Apr 24, 2021 at 6:29 AM Martin Flöser <<a href="mailto:mgraesslin@kde.org">mgraesslin@kde.org</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">Am Freitag, 23. April 2021, 11:58:07 CEST schrieb Jonathan Riddell:<br>
> <a href="https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_20593" rel="noreferrer" target="_blank">https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_20593</a><br>
> 5<br>
> <br>
> I've little interest in putting lots of apps into app stores without this<br>
> change of culture where app developers take some responsibility for the end<br>
> result.  It would likely end up with unmaintained apps.<br>
<br>
After reading through the merge request I have a feeling that you approach <br>
this in a not optimal way. Change management is difficult.<br>
<br>
Like Nate already wrote it is not clear how that merge request is aiming the <br>
goal and after being asked to explain you give a non explaining answer which <br>
certainly did not help. Sorry to say.<br>
<br>
I tried to think about what I would care about if I were maintainer of an app <br>
and also reflected a little bit on how I thought about packaging while <br>
maintaining KWin. My summary would be: I would not care for snaps.<br>
<br>
To me snap, flatpak, appimage is just the todays rpm, dep, ebuild, pkgbuild, <br>
etc. The vast amount of different standards makes it impossible to support them <br>
all which results in not caring for any.<br>
<br>
As an app maintainer I could imagine supporting appimage and/or flatpak. But <br>
not snap! With the unfree server component and the lack of proper alternatives <br>
it would go against my FLOSS nature given that there are truly free <br>
alternatives to distribute apps on linux. Similar my motivation to package for <br>
Windows or Mac as non-free platforms would be extremely low. Especially as it <br>
would mean investing lots of time to set it up and test it. Maintaining that <br>
would be lots of work, especially given that I mostly failed at keeping cmake <br>
dependencies correct. And don't remind me of how often Ben was angry with me <br>
for requiring new CI requirements without checking before (sorry!). Now it <br>
should be cmake, flatpak, appimage, snap, ms store, apple store, epic store, <br>
steam store, etc. etc. That's too much for most teams!<br></blockquote><div><br></div><div>Apologies for that Martin.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Given that I think your approach of changing culture is too strong, which is <br>
why I mentioned change management in the beginning.<br>
<br>
My personal suggestion would be to pick a few applications and try to work <br>
with them to get the tooling up. E.g. Krita, Kate, KWrite and Okular. And try <br>
to automate. Don't have the application developers maintain all those <br>
variants. It's too much! Maybe it's possible to get craft to a point that it <br>
can build for all of those platforms? Maybe it's possible to generate the <br>
required files directly with cmake? Give the devs one place to add their <br>
dependencies. Give them easy tools they know. If they have to invest looking <br>
into how to package for snap they will ask "what do I get over apt?"<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Now going back to my armchair,<br>
<br>
Cheers<br>
Martin<br>
<br>
<br></blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>