KDE 4.1 planning

[Aaron J. Seigo]

On Monday 07 January 2008, Sebastian Kügler wrote:
> 6 months also keeps the amount of changes surmountable. With a stable

surmountable is good. anemic is not. the cycle needs to be tuned to the size 
of the project and where it is in development. it's not unusual to see CMS 
projects with 6 or even 4 month dev cycles and just flourishing under it; but 
then their releases are full of tiny feature improvements with a relatively 
small set of big features.

the linux kernel manages largely by how they manage alternate trees and 
patches; it's realistic to note that the combination of svn and having dozens 
of rather discrete (though often interdependant) projects does hobble us to 
some extent here.

gnome releases these days are just one anemic set of changes after another. 
maybe they are spending too much time reimplementing the ui from scratch on 
every portable device, or maybe they are spending too much time on middleware 
like HAL or whatever ... i've also noticed that features and apps that start 
out in dev often don't fit within the first couple 6 month cycles and so end 
up getting included 3-4 cycles in; iow new application and large feature set 
performance is likely no better than with a 9 month cycle. and if you look at 
the 2 months following the first 6 month release cycle they had, commit list 
traffic and svn commits both fell dramatically and never recovered.

i've read papers showing that for some projects short cycles are a real 
hindrance, and other papers showing how they are a boon for other projects.

i guess that's a key point here: knowing what works for us and trying to 
understand why what does and doesn't work for other projects (so we can learn 
from them).

i understand you are looking at this from the POV of downstream distribution. 
that's a good thing, too. it's a bit like trying to get your new toy out in 
time for christmas. but the other major concern is that our development 
cycles fit our developers; delivering a lesser product but more often isn't a 
great thing.

perhaps there's a way to do both, though, with some strategy we haven't 
considered yet. i don't know, but its something i know i'll be thinking 
about.

if we do go for a june/july release of 4.1 perhaps we can also use that as a 
learning experience to see just how well it does work (though understanding 
that we do have a unusual load of 90% done stuf =). that's a process i'd be 
very comfortable with personally as it would give us some new experience, and 
if we're careful to be aware of the process as we go through i'm sure we'll 
learn a *lot* of useful things =)

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

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/release-team/attachments/20080107/d35a5548/attachment.pgp