Re: All About the Apps Goal

[Christoph Cullmann]

On 2021-04-23 21:04, Ben Cooksley wrote:

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.


I would prefer that, too.

I use the Craft produced installers for the Windows Store and
I hope to better test the Appimage stuff created there, too,
for Kate.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: All About the Apps Goal

[Ben Cooksley]

On Sat, Apr 24, 2021 at 6:29 AM Martin Flöser  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

Re: All About the Apps Goal

[Martin Flöser]

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!

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?"

Now going back to my armchair,

Cheers
Martin

Re: All About the Apps Goal

[Nate Graham]

Hello Jonathan,

I don't think people disagree with the broad outlines of the goal, but 
it's not obvious to me how the merge request in question supports it. 
Despite tons of discussion in the MR comments, It's hard for me to 
understand what the MR does. There is very little explanation of the 
"what" and the "why". I think maybe that's what's missing, maybe?


If it's to enable Snap support in KDE Gear packaging automatically, it 
would be good to put that in the MR description. And if people's 
objection to this is unclear maintainership for caretaking the Snap 
configuration, maybe you can volunteer in your role as goal leader to 
maintain the Snap configuration stuff? My impression is that you already 
do this anyway for Neon, so volunteering to do that would mostly be a 
matter of reassuring people that you'll keep doing what you already do :)


Nate


On 4/23/21 3:58 AM, Jonathan Riddell wrote:
KDE's All About the Apps Goal hopes to use modern methods of getting our 
apps to users.  I seem not to have been clear about what I mean by that 
so time to check in and ask again.  These days apps (and websites and 
any software) gets developed by developers who are empowered to deploy 
them all the way to the user through suitable QA.  In the apps of KDE 
apps that means using app stores (flathub, snap store, appimagehub, 
microsoft store, fdroid, google play etc) and integrating the packaging 
for those stores into the apps repos themselves and our release tools.


This is a massive change of culture compared to what KDE has largely 
done until now where the packaging and deployment have been separated 
into often entirely separated organisations.  That does not seem to have 
served us well, our software has not taken over the world except by 
other orgaisations who have followed these practices, such as KHTML's 
derivative now being used by Microsoft Edge. It's not a setup done 
anywhere outside the Linux distros and KDE has long aspired to move 
beyond just Linux distros.


Our most successful apps have long gone ahead and done this, Krita is 
now available on the Epic Games store.  It seems strange to me not to 
want to emulate that success.  Moving packaging into app repos makes it 
smoother


Recently I made a minimum viable patch for the KDE Gear release tooling 
to bump up the version numbers where those apps have snapcraft packaging 
files.  However I've been told I shouldn't "overstate the nature of the 
goal" with an objection to integrating the packaging into the app 
repositories.


https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_205935 



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.


So would KDE developers prefer the status quo where our packaging is 
deliberately separated from our app development?  Or can we start with 
moving, where appropriate for the teams doing the work, to move 
packaging into the app repos and link the apps with the users?


Jonathan

Re: All About the Apps Goal

[Aleix Pol]

On Fri, Apr 23, 2021 at 11:58 AM Jonathan Riddell  wrote:
>
> KDE's All About the Apps Goal hopes to use modern methods of getting our apps 
> to users.  I seem not to have been clear about what I mean by that so time to 
> check in and ask again.  These days apps (and websites and any software) gets 
> developed by developers who are empowered to deploy them all the way to the 
> user through suitable QA.  In the apps of KDE apps that means using app 
> stores (flathub, snap store, appimagehub, microsoft store, fdroid, google 
> play etc) and integrating the packaging for those stores into the apps repos 
> themselves and our release tools.
>
> This is a massive change of culture compared to what KDE has largely done 
> until now where the packaging and deployment have been separated into often 
> entirely separated organisations.  That does not seem to have served us well, 
> our software has not taken over the world except by other orgaisations who 
> have followed these practices, such as KHTML's derivative now being used by 
> Microsoft Edge. It's not a setup done anywhere outside the Linux distros and 
> KDE has long aspired to move beyond just Linux distros.
>
> Our most successful apps have long gone ahead and done this, Krita is now 
> available on the Epic Games store.  It seems strange to me not to want to 
> emulate that success.  Moving packaging into app repos makes it smoother
>
> Recently I made a minimum viable patch for the KDE Gear release tooling to 
> bump up the version numbers where those apps have snapcraft packaging files.  
> However I've been told I shouldn't "overstate the nature of the goal" with an 
> objection to integrating the packaging into the app repositories.
>
> https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_205935
>
> 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.
>
> So would KDE developers prefer the status quo where our packaging is 
> deliberately separated from our app development?  Or can we start with 
> moving, where appropriate for the teams doing the work, to move packaging 
> into the app repos and link the apps with the users?

Here's a separate ticket that is relevant to the topic:
https://phabricator.kde.org/T14380

I think it's important because it tries to address the same as the MR
without the actual technical changes in the way.

And for what it's worth, I don't think anyone has disagreed with the
general sentiment in any of the many places this has been posted.

Aleix

Re: All About the Apps Goal

[David Edmundson]

> Recently I made a minimum viable patch for the KDE Gear release tooling to 
> bump up the version numbers where those apps have snapcraft packaging files.  
> However I've been told I shouldn't "overstate the nature of the goal" with an 
> objection to integrating the packaging into the app repositories.

A goal does not define implementation.

That particular patch is confusing as it's claiming to be about giving
developers control, but it's changing a file in the release scripts to
take the control away from the app developers... the exact opposite of
your opening paragraph.

I'm probably understanding it wrong, but then so are others.

It's a technical discussion and as such requires an actual technical
response. Telling us it's for the goal or appealing to the community
with this thread isn't helping deal with the communication issues
which are clearly present on that MR to help everyone work out what
your masterplan is and how this fits in and actually works towards the
end goal.

David

Re: All About the Apps Goal

[Jonah Brüchert]

I don't think most people fundamentally object to maintaining packaging 
for stores, but not everyone is interested in all stores or knows how 
packaging for all those stores work.


Maybe an opt-in process would work, were the application maintainers are 
encouraged to move the packaging for a specific store to their 
repository, but only if they are willing to maintain it.


Personally for example, I already maintain flatpak recipes in some 
repositories, but I have little interest in looking into snap.


Some automation would be very nice, for example for updating to the 
latest runtime. That could be done as an automatic commit or just as a 
script which opens issues in repositories that use outdated runtimes.


Jonah




OpenPGP_0xA81E075ABEC80A7E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

All About the Apps Goal

[Jonathan Riddell]

KDE's All About the Apps Goal hopes to use modern methods of getting our
apps to users.  I seem not to have been clear about what I mean by that so
time to check in and ask again.  These days apps (and websites and any
software) gets developed by developers who are empowered to deploy them all
the way to the user through suitable QA.  In the apps of KDE apps that
means using app stores (flathub, snap store, appimagehub, microsoft store,
fdroid, google play etc) and integrating the packaging for those stores
into the apps repos themselves and our release tools.

This is a massive change of culture compared to what KDE has largely done
until now where the packaging and deployment have been separated into often
entirely separated organisations.  That does not seem to have served us
well, our software has not taken over the world except by other
orgaisations who have followed these practices, such as KHTML's derivative
now being used by Microsoft Edge. It's not a setup done anywhere outside
the Linux distros and KDE has long aspired to move beyond just Linux
distros.

Our most successful apps have long gone ahead and done this, Krita is now
available on the Epic Games store.  It seems strange to me not to want to
emulate that success.  Moving packaging into app repos makes it smoother

Recently I made a minimum viable patch for the KDE Gear release tooling to
bump up the version numbers where those apps have snapcraft packaging
files.  However I've been told I shouldn't "overstate the nature of the
goal" with an objection to integrating the packaging into the app
repositories.

https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_205935

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.

So would KDE developers prefer the status quo where our packaging is
deliberately separated from our app development?  Or can we start with
moving, where appropriate for the teams doing the work, to move packaging
into the app repos and link the apps with the users?

Jonathan

Re: Registration is OPEN & Submit Your Sticker Ideas!

[Kenny Duffus]

On Thursday, 22 April 2021 22:24:41 BST Halla Rempt wrote:
> That page and the page it links to really should mention the month Akademy is 
> going to happen. Maybe it's there, somewhere, but I cannot find it.
> 

I've added that to both pages now

Thanks

-- 

Kenny
(Pronouns: he/him)