Jonathan Gordon wrote:
> I'm not against the idea, but I wonder what the point of releasing so
> often is unless there was something big?
The point is to keep the most recent stable release recent. We want
users to (in general) use the releases, and if we stick to a relatively
short (and fixed) timescale between releases, then users know where they
stand - they can either use a current build and risk things going wrong,
or they can wait until the date of the next release to get whatever new
features/bug-fixes have been added.
> On your time line you have freeze, branch, release. What about tracker
> cleanup, manual fixes, mad rush to get ready patches in?
> I think we should either release every 4 months instead of 3 to give a
> bit more gap to do each one properly, or do similar to the ubuntu
> "schedule" where one release is a bugfix/stable one and the next is
> more about features (bug fixes still go in of course....)
I don't think releases are a big deal that need to have a specific goal
- they're just a "three-monthly build" that is known to have no
show-stopper bugs, and as up to date documentation as possible.
> I'm not suggesting adding every patch in the tracker which is in
> sync... I'm just trying to shrink the number of open patches. What I'm
> suggesting is that we do a call out onto the mailing lists saying if
> people have patches they want in and are willing to get them up to
> scratch then we are more open to have them committed. Doing this every
> release will probably be bad which is why I'm suggesting every second
I'm not sure how that's related to the idea of a fixed three-month
> Last thing... I wonder if 2 days before xmas is going to be workable?
> won't most people have more important IRL things to do?
I don't think of it as "2 days before xmas", but as "7 weeks from now".
So we all have the next 7 weeks to do anything we think needs doing to
prepare Rockbox for release.
My suspicion is that many devs will have free time over the Christmas
period to work on Rockbox, and we don't want people committing major
changes just prior to a release - just after a release is a far better time.
Received on 2008-11-05