Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide
Translations



Rockbox mail archive

Subject: Re: 3.0 - What MUST be done?

Re: 3.0 - What MUST be done?

From: Sander Sweers <sander.sweers_at_gmail.com>
Date: Wed, 31 May 2006 21:03:18 +0200

On Wed, 2006-05-31 at 09:47 +0100, Dave Chapman wrote:
> Hi,
>
> I agree with the people saying that we shouldn't release 3.0 or come out
> of feature freeze until it's "ready".
>
> But one of the problems, is that it isn't clear (at least to me), what
> are the outstanding tasks that MUST be done before we are happy to
> release 3.0.
>
> So my suggestion is that we (in this mailing list) decide conclusively
> what must be done before we're happy to release 3.0.
>
> A while ago (following a brief talk in IRC), I attempted to assign a
> "severity" rating to all outstanding 3.0 bugs as follows:
>
> Critical - bugs which MUST be fixed before 3.0
> High - bugs relating to audio playback
> Normal - bugs relating to core Rockbox
> Low - bugs relating to plugins

For me i would not assign the severity to specific functions of Rockbox.
That's where the categories come in. I'll give another way of organizing
below. My interpretation of the 4 severity's would be:

Critical - bugs that will eat all my oggs, offer my sister to the gods
and sell my soul.
High - bugs that could cause corruption on display or files or cause
 rockbox to seriously NOT behave in the audio output (like hard click,
beeps where there should not or stuttering)
Normal - bugs that are really annoying or make Rockbox less usable,
for example the battery indicator does not work)
Low - Typos documentation or far fetched features.

You guys might have a totally different view ;-)

> I've assigned bugs to the High/Normal/Low categories, but there are
> currently no bugs designated as "Critical". I just wasn't sure which
> ones were. Or can anyone suggest a better way to org anise them in FlySpray?
>

A better way of organizing in my opinion for your release blocker bugs
is to create a tracker bug named "[TRACKER - Rockbox release 3.x] and
make all the bugs/features that should be fixed for the 3.0 release
depend/block (i don't know how this works in flyspray) on it. Then when
the tracker bug has no more bugs depending on it you can release.

It gives you an instant overview of all the bugs preventing your
release.

> To conclude, my question is simply which bugs do people think fall into
> the "must fix" category? Are there any other issues not in the patch
> tracker? I can't see any reports about H300 battery life and only one
> about the Voice UI.

I have noticed something strange, will report it on the bug.

>
> Or do we feel that ALL the bugs are in the must-fix-before-3.0 category,
> in which case 3.0 is still a long way away.

IMHO I would not, all bugs in high and critical (assuming the scheme i
listed above) should get fixed but all in normal and low when there is
enough time. The h300 battery life would for me be in high or critical.
>
> Dave.

My thoughts on this are based on my experiences with other projects
(Gentoo being one of them). They use a different tracker (yes bugzilla)
but many of the organizational issues are the same.

My 2 cents

Greets
Sander
Received on 2006-05-31

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy