KDE 3.2 release cycle

[Aaron J. Seigo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 12 May 2003 02:08, Stephan Binner wrote:
> There are new widgets and functionality. I hope that the delay of
> KTabWidget ends this week with Qt 3.1 Beta 1. And there will be support for
> RandR and standards like vFolder or a better wm-spec implementation of new
> kwin.

the question is whether or not these features need to go out to the general 
users now, or whether the project is better served as a whole by waiting. the 
benefits are, in theory, less bugs and more features. if 3.1 is serving 
people very well, is 3.2 a mad-rush necessity? (that isn't rhetorical, btw =)

> Kexi and K3B are not affected by KDE release schedule.

i was merely pointing out that applications are the focus rather than the 
core; this is a bit different than in the past where core libraries were very 
much a central focus. in the case where applications are the focus, it is 
much easier to delay a core release...

> And khtml/kjs
> actually are within the core libraries and represent over one year
> improvement work (since the Apple team began to work on it) already today.
> Why not ship all this in 5 months from now as KDE 3.2 omitting alpha kdepim
> or only Kontact?

we could. we could also hold off until N7Y and make a decision then. This 
would mean a release no sooner than the end of November (allowing ~3 months 
freeze time), which is only 2 more months than your proposed 5 months from 
now.

> I consider Kig, JuK, Kgpg, Umbrello, Kopete and existings as mature enough
> to be shipped as stable and usable releases within 5 months. The only one
> which would fail this timeframe is Kontact? Then exclude it (like
> Kexi<->KOffice).

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.

> > coupled with Nove Hrady in August, this may well mean a longer release
> > cycle for 3.2. i don't think that this should become the new standard
> > pattern for all KDE releases, but not every release is the same.
>
> Not everything of the results of Nove Hrady will be implementable within 3
> months. Parts will require changes of Qt, so we will depend on the release
> date of Qt 3.2/4. Do you really think this will happen before Summer 2004?

of course not; which is why i specifically said "all those things that can be 
implemented in <3 months time". the larger changes can wait. 

we can roll all changes that are realistically achievable in a couple months 
into 3.2, release that, and then begin work on ++3.2. 

> > the only real concern i'd have is in the marketing department, and
> > keeping fresh in the mind of the user base and the Free software
> > community in general. i think this is what Mosfet was getting at
> > originally. i agree
>
> 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. look at 
Kopete for an example of that, IMO.

if we decide to release 3.2 in a shorter time frame, we should do it BEFORE or 
in COINCIDENCE with N7Y otherwise we'll just see a repeat of what happened 
prior to 3.0. i don't think KDE, the KDE developers, the KDE users, or the 
KDE supporting companies need a repeat of that.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE: The 'K' is for 'kick ass'
http://www.kde.org       http://promo.kde.org/3.1/feature_guide.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+wT9T1rcusafx20MRApdRAJ489Hv34AYELZ9+OyMcJlVy5GtQsACglWa6
3B/QJByTYyLj+eyML+uAbCY=
=b/Zg
-----END PGP SIGNATURE-----