Add kdeconnect-kde to release service

[Volker Krause]

On Wednesday, 11 December 2019 17:09:11 CET Nicolas Fella wrote:
> Hi,
> 
> we would like for KDE Connect to be included in the release service
> beginning with the 20.04 release.
> 
> As discussed with Jonathan I've moved the metadata to from extragear/network
> to kde/kdeutils.
> 
> I'm unsure about whether kdeconnect-android should move too or stay in
> extragear. I assume the release tooling is not prepared for releases to
> Google Play. We usually had separate releases for Android since we cannot
> align the rollout anyway.

Mobile apps in the release service is a good question though, I am interested 
in that for KDE Itinerary too.

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. 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?
(2) upstream F-Droid: for this we need actual releases, not binaries, quite 
similar to Linux distros
(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

Rollout to (2) and (3) does not necessarily be in sync with the release, 
that's also not the case for many other distributions.

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).

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/96639789/attachment.sig>