Rockbox mail archiveSubject: Re: 3.3 Feature Freeze
Re: 3.3 Feature Freeze
From: Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>
Date: Fri, 5 Jun 2009 00:31:05 +0200 (CEST)
Am Do, 4.06.2009, 22:40, schrieb Daniel Stenberg:
> Hello friends!
> In order to follow our grand tradition, we're now feature-frozen for 3.3
> unless there's something very major we've missed. We'll follow the
> established procedure of freezing for a week, then branch for a week, then
> / daniel.haxx.se
Well...I just was about to ask why we can't follow our "usual" time plan
(given we can call it usual after 3 releases).
I'm just thinking we can freeze, branch and release in the usual manner
(releasing on 23rd, branch a week before, freeze another week before).
That would "just" mean, that the devcon is during the branched phase. Is
this bad? I mean, the branch is just a second sanity time frame to fix the
very last few unexpeted bugs (i.e. We don't actually expect to fix bugs
during that time) and we can develop just fine in the trunk/ during that
time. Is that against doing much work at the devcon?
Well, I'm not going to discuss endlessly. I just wondered why this branch
time frame is so against the devcon. Also, I like traditions :) I'd
welcome if we released at 23rd nevertheless.
But I'm fine too if we can just chill at the devcon with the release being
behind us too. As long as it doesn't disturb the meeting, it will be
As for the release itself: Get on fixing bug, and let this release be as
stable as possible, even if we release a few days earlier! :)
After that, I hope we can get custom list, timestrech and pf core
integration as new features, as well as AMS Sansas and Samsung YH* as new
targets for 3.4 (and more I can't think about yet!).
Best regards and happy bug fixing!
Received on 2009-06-05