From kde-community  Sun Apr 21 08:27:09 2024
From: Volker Krause <vkrause () kde ! org>
Date: Sun, 21 Apr 2024 08:27:09 +0000
To: kde-community
Subject: Re: Proposal unify back our release schedules
Message-Id: <20401707.MxBFCYsqjC () vkpc27>
X-MARC-Message: https://marc.info/?l=kde-community&m=171368793732596
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart4682867.cLGnsYWvSu"

--nextPart4682867.cLGnsYWvSu
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Volker Krause <vkrause@kde.org>
To: kde-community@kde.org
Subject: Re: Proposal unify back our release schedules
Date: Sun, 21 Apr 2024 10:27:09 +0200
Message-ID: <20401707.MxBFCYsqjC@vkpc27>
Organization: KDE
MIME-Version: 1.0

On Sunday, 21 April 2024 00:37:03 CEST Ben Cooksley wrote:
> On Sun, Apr 21, 2024 at 1:51=E2=80=AFAM Kevin Ottens <ervin@kde.org> wrot=
e:
> > Hello,
> >=20
> > 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 shouldn=
't
> > > > > happen, so
> > > > > I'd argue: let's fix that instead.
> > >=20
> > > In my opinion the same goes for Gear depending on Plasma.
> >=20
> > 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.
> >=20
> > One thing I'm unsure for instance is: do we want to make Gear -> Plasma
> > dependencies completely forbidden?
> >=20
> > 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 mandato=
ry
> > Gear
> > -> Plasma dependencies, I agree are to forbid, but optional ones? I'm l=
ess
> > certain.
>=20
> 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.
>=20
> We probably need a home for "not quite Frameworks but shared libraries no=
ne
> the less" to make this achievable.
>=20
> 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 Workspa=
ce

One approach to solve that is/was to actually turn those into frameworks. A=
=20
bunch of PIM libraries were moved over time (KContacts, KCalendarCore, KDAV=
,=20
etc) already. More were lined up, the KF6 transition just put a pause on th=
at,=20
but e.g. KMime not too long ago received a bunch of API fixes in preparatio=
n=20
for this.

However, before continuing down that road I'd like to see a decision on the=
 KF=20
release schedule first now. With a much longer release cycle this becomes a=
 lot=20
less interesting to do.

Regards,
Volker
--nextPart4682867.cLGnsYWvSu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQQAnu3FVHA48KjZ07R/lszWTRLSRwUCZiTN3QAKCRB/lszWTRLS
R+uVAKCRunYQFeWvDJjCmAUYx/drPEys7QCgiKRnMi7ebdkyWZ5VXu0gAHlFBwk=
=qHEQ
-----END PGP SIGNATURE-----

--nextPart4682867.cLGnsYWvSu--