From: Paul Louden <paulthenerd_at_gmail.com>
Date: Mon, 29 May 2006 18:29:05 -0500

I think one major problem is that this release bit off more than it could
chew. One primary goal was to release for the H300, but to do that something
that needed to be done was solve the power problem.The _problem_ being that
I don't believe anyone has actually clearly identified what the problem is,.

It seems to me that for a proper release to happen (say, with 3.1) all new
features need to be in and functioning before the freeze (for example
TagCache is still incomplete) and changes should stay focusing on fixing
specific individual bugs (for example, the playback system rework should've
either been held until after the freeze, or the freeze end date should've
been announced as being dependent upon the results of that rework and any
bugs it may create.)

The main problem though is that many people, ESPECIALLY non-committers,
continue working on non-release code. People still write plugins or other
features. For the release perhaps the idea of a deadline/date should be
dropped entirely, and a list of bugs should be collected somewhere, with the
release "When these bugs are resolved". Then actually request that
non-committers help with those bugs too.

Right now the Release ToDo is fairly vague, saying X system needs work, but
not really clear on what to do, so I get the feeling that many external
developers who _might_ be interested haven't got a clear idea of what to
look at. And of course many others have just sorta vanished until the freeze
is over.

To summarize I suppose, it seems to me like there needs to be a clearer (and
more finite) goal with future freezes, with a specific list of what needs to
be done, if at all possible, and no feature work at all.

Just my views on the whole thing, though it should of course be noted that
I'm watching from outside. It's clear some of the problems that exist just
_can't_ be fixed within a timeline, because you can't say "We will discover
the cause of this bug in the next X days".

On 5/29/06, bk <mutualaid_at_gmail.com> wrote:
>
> Hey all,
>
> Since 3.0 didn't happen today (despite it being the proposed absolute
> deadline) I think some rethinking needs to be done about releases.
>
> Obviously there's some problems to deal with, since we've been in a
> freeze forever, there's little CVS activity and no clear indications on
> when a release might happen, what's holding it up or who even makes the
> final decision.
>
> Maybe with how development is now working so-called 'stable' releases
> aren't really suitable? Would it be better to just release a CVS tarball
> once every 30 days like wine used to do? The 2.x series is already out
> there so we could call the new tarballs something like
> "rockbox-3.20060531.tar.gz".
>
> Regardless of the release style I propose that something be done about
> communication. Let's appoint someone the title of release
> coordinator/manager who's job it is to get the devs together on a
> specific date or feature goal and make sure it gets stuck to. If we
> promise to release on a certain date it will happen. If it doesn't, the
> user/contributor community will get a specific list of reasons why and a
> new target date. I'm not saying the person would have dictatorial
> control, but instead that person would make sure that there's consensus
> among the core devs and that decision making is open and transparent.
>
> bk
>
Received on 2006-05-30