Add kdeconnect-kde to release service

[Volker Krause]

On Thursday, 12 December 2019 18:44:30 CET Nicolas Fella wrote:
> On Donnerstag, 12. Dezember 2019 18:17:45 CET Volker Krause wrote:
> > I think in general it would be very nice to have those includable as well,
> > following a standardized branching and versioning model and the associated
> > i18n workflows makes sense as much there as it does for desktop.
> > 
> > If at all the difference is in the distribution channels I think. For
> > Linux- based mobile distros there is probably very little difference as
> > well.
> For the Qt-based mobile apps that are also relevant on the desktop it makes
> sense to include them. kdeconnect-android is a bit special in the regard
> that it really is an Android-only app.
> 
> > Android can be different though, seeing three possible channels there:
> > (1) our self-hosted F-Droid repos, currently for debug nightly builds from
> > master, but presumably we could have those as well for release builds from
> > the stable branch?
> 
> Having stable releases in our repo is not something I see a use case for if
> they are also available from the official F-Droid, which is something I
> definitely want to see and am working on.

I don't see this as the same thing as the official F-Droid repo, but as a 
convenient way to get to the stable builds from binary factory (as you 
describe below), which then are essentially release candidate packages. So 
ideally that's what we test before tagging/pushing to the production/end user 
stores. Doing those uploads fully automatic and thus blindly seems a bit 
risky.

> > (2) upstream F-Droid: for this we need actual releases, not binaries,
> > quite
> > similar to Linux distros
> 
> What we need for this is 1) tagged releases in the git repository and 2)
> build scripts in the fdroid repository. I'm working on such a script for
> KTrip at the moment. Once this is accepted we can use it as a blueprint for
> other apps. AFAIU F-Droid is able to automatically update an app when a git
> tag is pushed, so releases wouldn't need action from the release team. The
> scripts would need some regular maintainance (checking for failures,
> adding/updating dependencies etc), but that would not need to be done by
> the release team.
> 
> > (3) Play Store: would probably benefit from (1), if that produces packages
> > we can (manually) upload there directly, without needing separate builds
> > or
> > signing infrastructure
> 
> My idea is that additionally to the nightly builds binary factory also
> builds release builds, i.e. from stable branches/tags, compiled in release
> mode without debug symbols etc. 

That's largely what I had in mind for (1), just with the additional small step 
of putting this into a F-Droid repo as do for the nightly development builds, 
so it's easier to test those packages. Anyway, tiny detail, the key is 
building release packages in the first place.

> Ideally upload would be done via some
> Google Play API, but I don't know if such API exists.
> 
> > So from that perspective I don't see much against including mobile apps.
> > However, do we need a way to clearly mark them as such to avoid them being
> > distributed on desktop? For Android-only cases like kdeconnect-android
> > that's a non-issue, but Kirigami-based mobile apps often build fine on
> > desktop too, but might offer a sub-standard user experience there
> > (certainly the case for KDE Itinerary).
> 
> I disagree on this. In my opinion those apps should be treated like our
> usual desktop apps (part of the release service or not). Mobile
> distributions are usually derived from desktop distros in some form so
> having them directly availabe would benefit the Linux mobile ecosystem.
> Furthermore, the vision of Kirigami is applications that work well on both
> mobile and desktop systems and not having them available on "normal"
> distros would undermine this vision.

In theory I agree. However that doesn't change that the user experience of KDE 
Itinerary is rather poor on desktop (and IMHO similar for some of the other 
largely mobile/touch focused Kirigami apps), so I'm looking for ways to manage 
expectations here.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20191212/72225127/attachment-0001.sig>