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