[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-community
Subject: Re: Proposal unify back our release schedules
From: Ben Cooksley <bcooksley () kde ! org>
Date: 2024-04-20 22:37:03
Message-ID: CA+XidOGQ6+gaPiqofYESTzR0RiPDGRRex9VKRVZabvkx=rmHaw () mail ! gmail ! com
[Download RAW message or body]
On Sun, Apr 21, 2024 at 1:51 AM Kevin Ottens <ervin@kde.org> 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 <ervin@kde.org> 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 Plasma.
>
> Agreed, just didn't want to muddy my message and so focused on only one
> direction. But it's definitely a topic to explore as well.
>
> 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 a Plasma session. So mandatory
> Gear
> -> Plasma dependencies, I agree are to forbid, but optional ones? I'm less
> certain.
>
I've considered whether it was feasible to ban such dependencies in the
past, however always ended up in the position that it wasn't feasible to do
so.
This will require a degree of projects being moved around, code being
broken out into separate modules, etc. but I think it is solvable given
enough commitment to do so.
We probably need a home for "not quite Frameworks but shared libraries none
the less" to make this achievable.
The usual tripping points ended up being:
- Various graphics and multimedia libraries such as libkdcraw, libkexiv2,
etc
- Various PIM libraries, often related to Akonadi integration for Workspace
- Components of Workspace that were sitting over in Gear, such as Baloo
(which shouldn't be used anywhere outside Plasma - yet is heavily
integrated in Dolphin, which arguably really belongs in Plasma not Gear as
well)
- Applications that published components and libraries that were reusable
by others such as Marble, Kompare and Okteta.
- Addon collections that due to shared D-Bus interfaces ended up being both
build and runtime dependencies (less so now, but kio-extras sits in this
territory to a certain extent)
- Components of Workspace, such as KSysguard that provide libraries whose
functionality is used
I'm not sure where KWin sits these days, but it's hard (and I mean very
hard) dependency on KWindowSystem within Frameworks was a source of quite a
bit of trouble in the past.
Dolphin is a serial offender in the same department when it comes to KIO -
it has a similarly hard dependency.
>
> > > > > * 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 of Framework and contribute to Framework.
> > >
> > > Changing the Frameworks release cadence away from monthly isn't going
> to
> > > get fixes out any faster - as if you are using distribution packages it
> > > still has to be packaged.
> > > If anything it will make them take longer as the Frameworks release
> would
> > > end up being every couple of months instead of monthly? (you can always
> > > build Frameworks locally if you need the fixes now)
> >
> > For (non-rolling) distributions that update packages on patch releases
> but
> > not on minor releases it would make a difference if there where patch
> > releases of Frameworks. Not all distributions can follow and backport
> > important fixes in Frameworks. At worst, users will have to suffer a bug
> in
> > Frameworks until the next LTS release.
> >
> > Regards,
> > Ingo
> --
> Kevin Ottens, http://ervin.ipsquad.net
>
> enioka Haute Couture - proud supporting member of KDE
> https://hc.enioka.com/en
Cheers,
Ben
[Attachment #3 (text/html)]
<div dir="ltr"><div dir="ltr">On Sun, Apr 21, 2024 at 1:51 AM Kevin \
Ottens <<a href="mailto:ervin@kde.org">ervin@kde.org</a>> \
wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Hello,<br> <br>
On Saturday 20 April 2024 15:12:48 CEST Ingo Klöcker wrote:<br>
> On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote:<br>
> > On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens <<a \
href="mailto:ervin@kde.org" target="_blank">ervin@kde.org</a>> \
wrote:<br> > > > The example you give shows Plasma depending on \
Gear, this shouldn't<br> > > > happen, so<br>
> > > I'd argue: let's fix that instead.<br>
> <br>
> In my opinion the same goes for Gear depending on Plasma.<br>
<br>
Agreed, just didn't want to muddy my message and so focused on only one \
<br> direction. But it's definitely a topic to explore as well.<br>
<br>
One thing I'm unsure for instance is: do we want to make Gear -> \
Plasma <br> dependencies completely forbidden?<br>
<br>
We might consider this going one step too far. I could understand if a Gear \
<br> app wants to provide "more integration" in a Plasma session. \
So mandatory Gear <br>
-> Plasma dependencies, I agree are to forbid, but optional ones? \
I'm less <br> certain.<br></blockquote><div><br></div><div>I've \
considered whether it was feasible to ban such dependencies in the past, \
however always ended up in the position that it wasn't feasible to do \
so.</div><div>This will require a degree of projects being moved around, \
code being broken out into separate modules, etc. but I think it is \
solvable given enough commitment to do so.</div><div><br></div><div>We \
probably need a home for "not quite Frameworks but shared libraries \
none the less" to make this achievable.</div><div><br></div><div>The \
usual tripping points ended up being:</div><div>- Various graphics and \
multimedia libraries such as libkdcraw, libkexiv2, etc</div><div>- Various \
PIM libraries, often related to Akonadi integration for \
Workspace</div><div>- Components of Workspace that were sitting over in \
Gear, such as Baloo (which shouldn't be used anywhere outside Plasma - \
yet is heavily integrated in Dolphin, which arguably really belongs in \
Plasma not Gear as well)</div><div>- Applications that published components \
and libraries that were reusable by others such as Marble, Kompare and \
Okteta.</div><div>- Addon collections that due to shared D-Bus interfaces \
ended up being both build and runtime dependencies (less so now, but \
kio-extras sits in this territory to a certain extent)</div><div>- \
Components of Workspace, such as KSysguard that provide libraries whose \
functionality is used </div><div><br></div><div>I'm not sure where \
KWin sits these days, but it's hard (and I mean very hard) dependency \
on KWindowSystem within Frameworks was a source of quite a bit of trouble \
in the past.</div><div>Dolphin is a serial offender in the same department \
when it comes to KIO - it has a similarly hard dependency.</div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
> > > > * We currently don't have a stable branch for \
Framework and it takes<br> > > > > often<br>
> > > > up to one month for fixes to be deployed. The Framework \
releases is<br> > > > > also<br>
> > > > not in sync with either Gear nor Plasma while these two \
modules<br> > > > > heavily<br>
> > > > make use of Framework and contribute to Framework.<br>
> > <br>
> > Changing the Frameworks release cadence away from monthly \
isn't going to<br> > > get fixes out any faster - as if you are \
using distribution packages it<br> > > still has to be packaged.<br>
> > If anything it will make them take longer as the Frameworks \
release would<br> > > end up being every couple of months instead of \
monthly? (you can always<br> > > build Frameworks locally if you need \
the fixes now)<br> > <br>
> For (non-rolling) distributions that update packages on patch releases \
but<br> > not on minor releases it would make a difference if there \
where patch<br> > releases of Frameworks. Not all distributions can \
follow and backport<br> > important fixes in Frameworks. At worst, users \
will have to suffer a bug in<br> > Frameworks until the next LTS \
release.<br> > <br>
> Regards,<br>
> Ingo<br>
-- <br>
Kevin Ottens, <a href="http://ervin.ipsquad.net" rel="noreferrer" \
target="_blank">http://ervin.ipsquad.net</a><br> <br>
enioka Haute Couture - proud supporting member of KDE<br>
<a href="https://hc.enioka.com/en" rel="noreferrer" \
target="_blank">https://hc.enioka.com/en</a></blockquote><div><br></div><div>Cheers,</div><div>Ben \
</div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic