KDE 4.1 planning

Simon Edwards simon at simonzone.com
Tue Jan 8 08:56:29 CET 2008

Aaron J. Seigo wrote:
> On Monday 07 January 2008, Mauricio Piacentini wrote:
>> Now that the big baby is out, we can attempt to pack 
>> less changes into each release, but make them more frequent. If
>> something is not ready by 4.1, then 4.2 is not that far away. Rinse,
>> repeat. A 9 month interval for inclusion of new features and
>> applications in the main release seems too long, at least for me.
> it's actually a 7 month interval, not 9. it worked well in the 3.x and 2.x 
> days. it's also useful to remember than not everyone starts developing on the 
> first day. our contributors, for work or personal reasons, often start and 
> stop throughout the devel cycle. if the calendar-time window is too small 
> we'll miss fitting some (many, even) of the man-hour sets needed to complete 
> a given set of features. 

For each new feature there is an optimum development schedule length, be 
it 9 months, 6 or 3.14159 months, but it is always different for each 
feature. A fixed schedule like 6 or 9 months is always going to small 
(not enough time for big features), or too long (completed small 
features waiting around in SVN for ages before release). So I think the 
goal should be to minimise the time penalty of a feature not fitting the 
schedule. This pushes me towards shorter schedules.

As for whether this means less feature development, I would say no, it 
doesn't make a real difference. There are still only 24 hours in a day 
for hacking, 12 months a year, regardless of how you divide that up. For 
most developers who developer when they can find the spare time, 
planning a calendar based schedule for a feature isn't really practical. 
Real life tends to intervene.

Of course a shorter schedule incurs more release process overhead.

I see the KDE releases more as "a bus to be caught", and less as a 
schedule for my development. YMMV.

I think that with a project the size of KDE which contains so many 
smaller (relatively speaking) sub-projects, the SVN trunk should be kept 
in a fairly stable state almost all the time. The development window in 
the schedule should be used for landing and integrating large features 
that have been developed and stablised on their own feature branch.

just my take on it.


Simon Edwards             | KDE-NL, Guidance tools, Guarddog Firewall
simon at simonzone.com       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."

More information about the release-team mailing list