On Sun, Jul 24, 2005 at 12:15:28PM -0300, bulia byak wrote:
I agree we should try to make it faster, but I doubt a month per release is realistic. There's too much stuff to do for each release. 0.41 was about as fast as it gets, and it was more than 2 months.
One thing that I've learned with releases is that the more frequently you do them, the easier it becomes, because you tend to script repetitive tasks and streamline processes. As well, the bug fixing phases are shorter with short release cycles since less new code is going in. We've seen this for our past releases.
The motivation to get the release work done seems to be strongest when a release is pending. As Jon pointed out, if we set our goal to 1 month, it could take 1.5 to 2; if we set it at 2 months, then it could turn out to be 3. So I think we should shoot for 1 month, and then if we're a bit late, it still gives the Summer of Code students at least one opportunity to see their code in practice before they have to turn it in.
Also I think the best approach would be to alternate long and short releases, because long releases have their advantages too. So let's try to make each odd release as short as possible, so we can take our time on even releases.
Sounds good to me. That'll make it easy to remember.
Bryce