[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: Proposal unify back our release schedules
From:       Michael Reeves <reeves.87 () gmail ! com>
Date:       2024-04-24 22:26:10
Message-ID: 050cbccb-b7ca-46d1-a8a8-1e1e6911161f () gmail ! com
[Download RAW message or body]

[Attachment #2 (text/plain)]

For the same reason they are sometimes seen as convenient this type of \
container format can be a pain when a security patch or bug fix needs to be \
propagated to every app that uses a library on an individual basis. Also \
some app image formats like flatpak are very restrictive by default on what \
they allow an app to do. Something to think about as we will get bugs \
related to that if app images become the primary distribution mechanism.

Apr 24, 2024 1:56:30 PM Martin Flöser <mgraesslin@kde.org>:

> Am Freitag, 19. April 2024, 11:04:33 CEST schrieb Carl Schwan:
> > Currently this is just a proposal, not a vote proposal or anything like
> > that. I'll be happy to receive positive or negative feedback on this \
> > idea.
> 
> Reading through the proposal and the discussion, I think we need to think \
> a little bit outside of the box. I have the feeling that most devs still \
> see Linux distributions as the primary way to distribute our software. I \
> do not think that this is universal true anymore and if we move away from \
> it, this would open up way new possibilities.
> 
> Let's assume for apps we see Flathub/Snaps/Windows Store/whatever store \
> as our primary distribution channel, this would give us quite some \
> advantages: 
> * less duplicated work for distributions
> * no problems with "this framework release is not packaged yet"
> * no overwhelmed work for distributions due to too many packages need to \
> be updated
> * no need to push an update if nothing changed
> * no random "this pulls in KDE" due to incorrect packaging
> * always up to date software for our users
> * no bad experience due to missing (optional) dependencies
> * easy release for the maintainers without needing a release team (what \
> about a Gitlab create release pipeline the maintainer can press)
> 
> So this would totally open up a new way to release and distribute "Gear". \
> And with Gear being easily available for everyone this would also give \
> the possibility to move things into Plasma which belong into Plasma, but \
> haven't been for "this is an app and also usable on other desktop". What \
> comes in my mind is everything that are essential apps for a decent \
> desktop experience: 
> * dolphin
> * spectacle
> * an image viewer (gwenview/koko, etc.)
> * okular
> * ...
> 
> Those could still be apps, but be released together with Plasma, thus \
> also tightly integrate with Plasma while at the same time be distributed \
> through other channels.
> 
> Such a model should also help with the development experience. I read a \
> few comments about it being a problem on depending on frameworks master - \
> I agree that is a problem. But not so much if there is always an up to \
> date development container available to pull and hack on. If apps are
> containerized, their build environment can also be containerized.
> 
> So my suggestion: think about more than just the release cycle and the
> alignment of the releases if you are going to touch this (hot) topic.
> 
> Cheers
> Martin


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]