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