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
signature.asc
Description: This is a digitally signed message part.
