[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Release schedule
From:       Thomas Zander <zander () kde ! org>
Date:       2007-11-05 18:19:58
Message-ID: 200711051920.03493.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 05 November 2007 18:59:36 Bart Coppens wrote:
> Personally, I don't like a 6 months release cycle. It's too short for
> KOffice, IMO. Not that I'm coding much these days, but I really think 6
> months is too short for a relatively small project like KOffice.
>
> Based on past experience, I think it is far more reasonable to have at
> at least 9 months between releases: ~7 months unrestricted feature
> adding, 1 month stabilizing features, stringfreeze, and 1 month only
> bug fixing.

While I agree on your experience, I don't think the past has to be such a 
strong guide for the future.
The features that get added in coming releases can be done in branches if 
they are big, and only incorporated when its ready.  This means that you 
can happily start a big new feature without having the obligation to 
finish it for the upcoming release if you don't have time to work on it. 
It will just be merged for the release after.

At the same time we have learned to add a lot of unit tests (right?!? ;).  
This actually makes your bugfixing time shorter due to you finding your 
bugs even before you commit your stuff.

All this works both ways, naturally, if you are able to work with these 
techniques (and lots of companies / professionals do) you get closer to a 
time-based release. And at the same time if you are forced to rely on 
your unit tests, you will add more and you will actually have more fun 
adding a new feature being reasonably sure you won't be debugging it for 
the next month.

So, bottom line, in the past we (indeed) clearly failed to do time-based 
releases due to various reasons. The question thus becomes if we can 
change the way we work to allow time-based releases to actually work.

I personally think that even if some people have doubts, we should aim for 
6 months and do our collective best to make it.  Working with suggestions 
people that have experience with time-based releases can give. Naturally 
that doesn't mean we will release it no matter what.
-- 
Thomas Zander

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]