[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Fwd: Re: [Dlc-discuss] Inhibitors to the desktop
From:       Ralf Nolden <nolden () kde ! org>
Date:       2004-01-17 20:39:48
Message-ID: 200401171239.53726.nolden () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 17 January 2004 08:43, Kevin Krammer wrote:
> On Saturday 17 January 2004 16:47, Erik K. Pedersen wrote:
> > Lørdag 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 
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 
the KDE infrastructure (read: mailinglists, 
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 
handle.

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

Essentially, the discussion can be summarized as:

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

My conclusion would be:

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

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

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

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

Ralf

>
> Cheers,
> Kevin

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

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

[Attachment #5 (application/pgp-signature)]

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


[prev in list] [next in list] [prev in thread] [next in thread]