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 release.
I'm not sure how that's related to the idea of a fixed three-month release cycle.
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.
Dave.
