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.
cheers,
--
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