Add kdeconnect-kde to release service
vkrause at kde.org
Thu Dec 12 19:01:39 GMT 2019
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
> > (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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: This is a digitally signed message part.
More information about the release-team