From kde-core-devel  Tue Oct 03 10:53:03 2006
From: Kevin Krammer <kevin.krammer () gmx ! at>
Date: Tue, 03 Oct 2006 10:53:03 +0000
To: kde-core-devel
Subject: Re: [RFC] How to handle backends properly?
Message-Id: <200610031253.11023.kevin.krammer () gmx ! at>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=115987282504072
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart2050998.mO2Bq63Mxg"

--nextPart2050998.mO2Bq63Mxg
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 01 October 2006 14:21, Maksim Orlovich wrote:
> > One of the point of those backends is to be able to make a release when=
 a
> > subsystem see its behavior changing (like in the transition from HAL 0.4
> > to
> > 0.5 for instance). Hosting them in kdebase or kdemultimedia doesn't
> > really support this idea.
>
> How far is HAL from 1.0? It seems that this need has more to do with its
> immaturity/lack of API stability than anything else, so hopefully it will
> stabilize some point soon, removing this headache...

HAL is just an example.
We depend on other software developed by other projects and released on the=
ir=20
own schedule, IIRC there will be a WiFi API related change in one of the ne=
xt=20
Linux kernel versions.

Since the main concern seems to be proper packaging, we probably should try=
 to=20
get feedback from the packagers, especially of those distributions that ten=
d=20
do make their users suffer by just creating huge monolithic packages.

Cheers,
Kevin

=2D-=20
Kevin Krammer <kevin.krammer@gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtcentre.org

--nextPart2050998.mO2Bq63Mxg
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBFIkEWnKMhG6pzZJIRAu6AAJ90AjJMvKYVX3qrshi0Yz3ncBwNsQCfR6oh
n8X2h4qwEUhBSOmpjuhbY/4=
=P253
-----END PGP SIGNATURE-----

--nextPart2050998.mO2Bq63Mxg--