Add kdeconnect-kde to release service

[Ben Cooksley]

On Fri, Dec 13, 2019 at 6:44 AM Nicolas Fella <nicolas.fella at gmx.de> 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.
> > (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. Ideally upload would be done via some Google Play
> API, but I don't know if such API exists.

With the way Android builds are currently conducted (building every
single dependency from scratch each time) i'm opposed to doing this as
it would double what is already quite an expensive load on the system
already.

I'd like to see the Android build process optimised to let it reuse
the results for most dependencies (Frameworks come to mind in
particular) before we head in that direction.

>
> > 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.
>
> Cheers
>
> Nico
>
>
>

Cheers,
Ben