KDE 3.2 release cycle

Bernhard Reiter bernhard at intevation.de
Fri May 16 17:18:02 BST 2003


On Tuesday 13 May 2003 20:54, Aaron J. Seigo wrote:
> the KDE PIM stuff is more important than all the other applications you
> mentioned put together from the standpoint of user benefit. this is not to
> put down those other apps, since i think they are all great and
> strategically important. rather, this speaks to the overwhelming importance
> of a solid PIM infrastructure and application set in KDE.

I can second this as many coporate users hope
that KDE 3.2 will be able to natively act as a Kolab client.

> On Monday 12 May 2003 02:08, Stephan Binner wrote:
> > Yes, it will lead to the breakage of KDE's monolithic releases with more
> > apps being part of KDE or parts released indepently released by someone.
>
> i'm not sure why this is a bad thing in an of itself? if KDE was to stop
> doing monolithic releases altogether, sure. but having independent and
> timely releases of apps leading up to a monolithic release can be healthy.

I believe that breaking up responsibility for the growing KDE complex
will be crucial at some point in the future.
The important a library or components is, 
the more conservative the release decisions should be.
The only way to archive this is to have one person or group "defend"
"their" component and decide on its release or branch situatution
independently from other components.

Not being a KDE core developer I draw from my experience 
with the Ägypten and Kroupware projects.
It is very hard to get a good base for KDE components 
to produce solutions which are rock solid and ready for the end user.
I've spend considerable amount of time in the last 1.5 years
quality testing software build on (some) KDE components.
The number of times things broke because of other changes
in theoretically unrelated KDE parts was too high.
This just as an impression that split up releases by KDE
of the various KDE building blocks 
could further leverage the good work of the KDE developers. 

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3052 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030516/53c17133/attachment.bin>


More information about the kde-core-devel mailing list