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
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
On Saturday, 20 April 2024 15.50.58 CEST Kevin Ottens wrote:
> One thing I'm unsure for instance is: do we want to make Gear -> Plasma
> dependencies completely forbidden?
>
> We might consider this going one step too far. I could understand if a Gear
> app wants to provide "more integration" in
On Friday, 19 April 2024 18.39.01 CEST Kevin Ottens wrote:
> > * We end up with 3 different products which are released at different
> > times
> > but are connected together. Apps and Plasma both need Framework, Plasma
> > needs some packages from gear like kio-extra, Gear needs some package from
> As a result I'll rescind my idea to slow down Frameworks feature
> releases.
Then I'll take over and fight for it!
>that having a fast Frameworks release cycle allows
> people developing apps with features in Frameworks to not have to live
> on master like we do in Plasma.
That was the
On Mon, Apr 22, 2024 at 2:29 PM Nate Graham wrote:
>
>
>
> On 4/22/24 19:19, Albert Astals Cid wrote:
> > El dilluns, 22 d’abril del 2024, a les 17:12:46 (CEST), Nate Graham va
> > escriure:
> >> Now, let's say we make Gear use Plasma's current release schedule by
> >> syncing up the feature
On 4/22/24 19:19, Albert Astals Cid wrote:
El dilluns, 22 d’abril del 2024, a les 17:12:46 (CEST), Nate Graham va
escriure:
Now, let's say we make Gear use Plasma's current release schedule by
syncing up the feature releases and adopting the Fibonacci bugfix
releases. If we don't end up
Hello,
On Monday 22 April 2024 18:08:04 CEST Carl Schwan wrote:
> On Friday, April 19, 2024 6:39:01 PM GMT+2 Kevin Ottens wrote:
> > Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker
> > here I think. I'll try to add a couple of extra aspects to feed the
> > thinking on this
El dilluns, 22 d’abril del 2024, a les 17:12:46 (CEST), Nate Graham va
escriure:
> Ok, so happily I actually see quite a bit of agreement here, regardless
> of what else we do.
>
> 1. Fibonacci bugfix releases are good, and we could benefit from having
> Gear adopt these.
>
> 2. Severing
On Friday, April 19, 2024 6:39:01 PM GMT+2 Kevin Ottens wrote:
> Hello,
>
> Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker here
> I think. I'll try to add a couple of extra aspects to feed the thinking on
> this topic.
Thanks you all for raising some important points.
Ok, so happily I actually see quite a bit of agreement here, regardless
of what else we do.
1. Fibonacci bugfix releases are good, and we could benefit from having
Gear adopt these.
2. Severing implicit dependencies is a good idea. Shared libraries in
Gear are especially problematic and
>> in that event I'd like for us to put it
>> to a formal KDE e.V. vote
> Is this an eV topic?
Yes and no.
The original decision had a big impact, changing things again will
have a big impact. It's not something that should be decided by a few
people, nor is it something that should be decided
On Sunday, 21 April 2024 00:37:03 CEST Ben Cooksley wrote:
> On Sun, Apr 21, 2024 at 1:51 AM Kevin Ottens wrote:
> > Hello,
> >
> > On Saturday 20 April 2024 15:12:48 CEST Ingo Klöcker wrote:
> > > On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote:
> > > > On Sat, Apr 20, 2024 at 4:39
On Sun, Apr 21, 2024 at 1:51 AM Kevin Ottens wrote:
> Hello,
>
> On Saturday 20 April 2024 15:12:48 CEST Ingo Klöcker wrote:
> > On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote:
> > > On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote:
> > > > The example you give shows Plasma
On Fri, Apr 19, 2024 at 9:39 AM Kevin Ottens wrote:
> Hello,
>
> ::most history snipped::
>
> And then have a single big marketing
> announcement for a Plasma x.y.2 per year with its own marketing name.
>
> ::snip::
>
> > * Only have one release announcement on our website. We can call
On Freitag, 19. April 2024 22:51:55 CEST Jakob Petsovits wrote:
...
> all KF dependencies from source. Now that all the megarelease is out, we
> might want to consider relying on distro packages for KF6 by default, in
> the same way that Qt is not built by default either. This would underscore
>
Hello,
On Saturday 20 April 2024 15:12:48 CEST Ingo Klöcker wrote:
> On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote:
> > On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote:
> > > The example you give shows Plasma depending on Gear, this shouldn't
> > > happen, so
> > > I'd argue:
On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote:
> On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote:
> > The example you give shows Plasma depending on Gear, this shouldn't
> > happen, so
> > I'd argue: let's fix that instead.
In my opinion the same goes for Gear depending on
On Freitag, 19. April 2024 14:26:45 CEST Sune Vuorela wrote:
> It might make sense for plasma and gear to follow the same schedule. But
> I really like what we have going with frameworks.
>
> One issue that leads to the 'frameworks stable, release monthly' was
> that sometimes, even often, you
i know quite a few have responded to this, but as the big warning on this,
the fact that the three parts cant be released independently, is a big
warning flag that a overhaul is needed of the overlapping architecture.
i know this is a big issue, and the bigger the project, the bigger the
Others have made convincing arguments for not tying the projects together from
an engineering point of view, which I find easy to agree with. I also like the
current monthly KF schedule in that it allows me to submit MRs early on in a
Plasma development cycle and use them in Plasma shortly
On Fri, Apr 19, 2024 at 11:35 AM Volker Krause wrote:
>
> On Freitag, 19. April 2024 11:04:33 CEST Carl Schwan wrote:
> > * We currently don't have a stable branch for Framework and it takes often
> > up to one month for fixes to be deployed. The Framework releases is also
> > not in sync with
On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote:
> Hello,
>
Hi all,
>
> Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker
> here I
> think. I'll try to add a couple of extra aspects to feed the thinking on
> this
> topic.
> On Friday 19 April 2024 11:04:33 CEST Carl
Hello,
Wished to react to a point in there. :-)
On Friday 19 April 2024 17:33:02 CEST Volker Krause wrote:
> On Freitag, 19. April 2024 11:04:33 CEST Carl Schwan wrote:
> > * We currently don't have a stable branch for Framework and it takes often
> > up to one month for fixes to be deployed.
Hello,
On Friday 19 April 2024 14:03:01 CEST Luigi Toscano wrote:
> Nate Graham ha scritto:
> > I expect a vast amount of discussion to result from this proposal, and I
> > think that's great. It'll be good to talk about it. But I suspect in the
> > end we'll likely not achieve 100% consensus,
Hello,
Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker here I
think. I'll try to add a couple of extra aspects to feed the thinking on this
topic.
On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote:
> I know this might be a controversial idea, but I would like to
On Freitag, 19. April 2024 11:04:33 CEST Carl Schwan wrote:
> * We currently don't have a stable branch for Framework and it takes often
> up to one month for fixes to be deployed. The Framework releases is also
> not in sync with either Gear nor Plasma while these two modules heavily
> make use
On Friday, April 19, 2024 2:03:45 PM GMT+2 Luigi Toscano wrote:
> We also have and we will continue to have applications which are not on this
> schedule, and thus KDE will continue to be unfit as a general brand for
> them. The work to reduce the dependencies improved with the move to Qt 6
>
On 2024-04-19, Carl Schwan wrote:
> Hello Community,
>
> I know this might be a controversial idea, but I would like to propose reunify
> our release schedules. I feel like splitting our releases schedules between
> Frameworks, Plasma and Gear is not working as well as we intended it to be
>
(apologize, resending, I've missed a CC)
Carl Schwan ha scritto:
> Hello Community,
>
> I know this might be a controversial idea, but I would like to propose reunify
> our release schedules. I feel like splitting our releases schedules between
> Frameworks, Plasma and Gear is not working as
Nate Graham ha scritto:
> I expect a vast amount of discussion to result from this proposal, and I think
> that's great. It'll be good to talk about it. But I suspect in the end we'll
> likely not achieve 100% consensus, and in that event I'd like for us to put it
> to a formal KDE e.V. vote so
Carl Schwan ha scritto:
> Hello Community,
>
> I know this might be a controversial idea, but I would like to propose reunify
> our release schedules. I feel like splitting our releases schedules between
> Frameworks, Plasma and Gear is not working as well as we intended it to be
> when
> we
Thanks for taking the time to assemble this email, Carl. These are
arguments I've brought up individually myself for years, and I think
they have merit.
Taken together, for me they paint a picture of a project that was
attempted, faithfully executed on, but didn't end up delivering the
Hello Carl,
Promotion-wise it makes sense. We always have difficulty explaining and, hence,
making the general public feel excited about the new versions of Plasma, as
the concept of "desktop environment" is a concept that escapes (and bores)
most people. But promoting a bunch of new apps, and
34 matches
Mail list logo
