--0000000000009cc6d606168ed887 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 21, 2024 at 1:51=E2=80=AFAM Kevin Ottens wrote: > Hello, > > On Saturday 20 April 2024 15:12:48 CEST Ingo Kl=C3=B6cker wrote: > > On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote: > > > On Sat, Apr 20, 2024 at 4:39=E2=80=AFAM 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 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 les= s > 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 alwa= ys > > > 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 bu= g > 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 --0000000000009cc6d606168ed887 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Apr 21, 2024 at 1:51=E2=80=AFAM K= evin Ottens <ervin@kde.org> wrot= e:
Hello,

On Saturday 20 April 2024 15:12:48 CEST Ingo Kl=C3=B6cker wrote:
> On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote:
> > On Sat, Apr 20, 2024 at 4:39=E2=80=AFAM Kevin Ottens <ervin@kde.org> wrote: > > > The example you give shows Plasma depending on Gear, this sh= ouldn'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 -> Pla= sma
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 m= andatory 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 qu= ite Frameworks but shared libraries none the less" to make this achiev= able.

The usual tripping points ended up being:
- Various graphics and multimedia libraries such as libkdcraw, libk= exiv2, etc
- Various PIM libraries, often related to Akonadi inte= gration 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 belong= s in Plasma not Gear as well)
- Applications that published compo= nents and libraries that were reusable by others such as Marble, Kompare an= d Okteta.
- Addon collections that due to shared D-Bus interfaces= ended up being both build and runtime dependencies (less so now, but kio-e= xtras sits in this territory to a certain extent)
- Components of= Workspace, such as KSysguard that provide libraries whose functionality is= used=C2=A0

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.
=C2=A0

> > > > * We currently don't have a stable branch for Frame= work 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 packa= ges it
> > still has to be packaged.
> > If anything it will make them take longer as the Frameworks relea= se 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<= br> > releases of Frameworks. Not all distributions can follow and backport<= br> > important fixes in Frameworks. At worst, users will have to suffer a b= ug in
> Frameworks until the next LTS release.
>
> Regards,
> Ingo
--
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
h= ttps://hc.enioka.com/en

Cheers,
Ben=C2=A0
--0000000000009cc6d606168ed887--