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
pgpg89d3dkjFw.pgp
Description: PGP signature
_______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
