[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]