--===============0549253420==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	micalg=pgp-sha1; boundary="Boundary-02=_Z2ZCAFBX5sdGU3K";
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


--Boundary-02=_Z2ZCAFBX5sdGU3K
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Saturday 17 January 2004 08:43, Kevin Krammer wrote:
> On Saturday 17 January 2004 16:47, Erik K. Pedersen wrote:
> > L=F8rdag 17 januar 2004 09:12   skrev Troels Tolstrup:

> I'd say if an application is important its author should be invited to
> maintain it in KDE's CVS.
Right, that's the sense of extending KDE - we did that with kopete for=20
instance and with other tools like KGPG.

> If it does not need more release than KDE, a KDE module is fine.
> If it needs more release, put it in kde-extra-gear.
Right, that is part of the idea. And that of course everyone is invited to =
use=20
the KDE infrastructure (read: mailinglists,=20
developer,translator,documentation help) when writing a KDE program.

> In the second case the packagers need to know which version of the
> application is considered good for the KDE release.
> Assuming that the following is compatible to the way KDE releases are
> handled, I suggest that KDE extra gear maintainers set the KDE release tag
> on their modules to the version of their lastest release (or to a version
> they think works best ith current KDE)
Good idea. I think you can even refine that a bit more to make it easier to=
=20
handle.

> I hope I did make at least some sense :)
Yes, it actually makes very good sense. I think that way we can also=20
"outsource" programs like kdat and other stuff that "bloats" the KDE core=20
modules.

Essentially, the discussion can be summarized as:

=2D How do we combine core modules' slow release cycles with higher release=
=20
demand
=2D How can we concentrate on the stuff that is important to the user and=20
shipping that with the core of KDE at the same time as a KDE release happens

My conclusion would be:

=2D go through the modules except kdelibs and kdebase. Sort out if it *real=
ly*=20
needs to be a part of the KDE core modules. If not, outsource it to=20
kdeextragear.
=2D if a new application is developed at a high feature rate that requires =
the=20
authors to make releases every couple of weeks for testing, kdeextragear is=
 a=20
good place to put it until the program matured to the point where the relea=
se=20
cycle slows down to the extend that, in case the program would be of really=
=20
good use for any desktop user (like cd burning, digital camera apps in this=
=20
case), it would be good to move it to one of the KDE core modules and gets=
=20
shipped with KDE.

I'm not only speaking about this because I'm packaging KDE for debian - I'm=
=20
interested in our task at KDE: providing a good desktop environement and th=
e=20
necessary utilities bundled with it so they are in the best shape=20
(translations and documentation). So, I'd say how about talking again with=
=20
Renchi (the digikam author, visit kde-apps.org and search for digikam or lo=
ok=20
at digikam.sf.net) if he would like to put his program into kdeextragear-1=
=20
where k3b resides currently as well so these programs can share code and=20
integrate better ? Ultimately, one could think of something like a=20
"Multimedia Center" that would be a container app and integrate:

=2D ripping cd's (kaudiocreator)
=2D burning cd's/dvd's (k3b)
=2D dealing with digital cameras (digikam)
=2D creating labels for cd's (kcdlabel or something)

Any comments ? I would like to continue discussing the subject to make KDE=
=20
easier for the end user, because the end user doesn't go for every app he=20
needs, he expects us to provide him these apps bundled into one core=20
distribution so that KDE as a desktop, shipped as it is, provides all the=20
everyday functionality (that's why we ship games, too :))

Ralf

>
> Cheers,
> Kevin

=2D-=20
We're not a company, we just produce better code at less costs.
=2D-------------------------------------------------------------------
Ralf Nolden
nolden@kde.org

The K Desktop Environment       The KDevelop Project
http://www.kde.org              http://www.kdevelop.org

--Boundary-02=_Z2ZCAFBX5sdGU3K
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQBACZ2Zu0nKi+w1Ky8RAlk5AKCKntDPqVVeV4jXKXZpLOghmY3CDQCfdU+o
r+73YDPRtDCh1ZTnEigHXps=
=IV5n
-----END PGP SIGNATURE-----

--Boundary-02=_Z2ZCAFBX5sdGU3K--

--===============0549253420==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

--===============0549253420==--