From: Zakk Roberts <midkay_at_gmail.com>
Date: Tue, 30 May 2006 16:37:18 -0700

Well, I think I'll toss my two cents in...

There have been a few occasions where I simply head to the Flyspray
bug reports page, pick out one that's rather simple, fix, and commit
it. I'm quite the opposite of a 'core dev' - I hardly know enough to
fix half the bugs on the tracker (especially the playback ones).
Having said that, I'd quite like to fix smaller things more often.

The problem for me is mostly involving the tracker. There are some
duplicate and "irrelevant" reports, as well as rather ambiguous ones,
and reports for the same build/model I'm using but I'm not able to
reproduce it, even if steps are provided. For example, we get a lot of
iPod bug reports, and the policy is not clear to me on how aggressive
we should be about closing them because they aren't supported models.
I think several of the 'should-be-fixed' ones are also still open even
after fixes are committed with comments from the devs asking "is this
fixed with latest CVS?" and getting no response; we/I can't really
close it because we don't know if it's fixed, but that's just another
one sitting in the list as a 'bug' that probably is no longer. I'd
really *like* to clean up the bug reports page, and every time I try
to do it I give up because I just don't know what should be done with
them. Clearer guidelines for that would help, IMO. Also, I second that
the ReleaseTodo should be more specific - I think for 3.1 we should
try to be a bit more firm about this. We should be more specific and
descriptive about what exactly needs to be done, and what should be
done, and keep it up to date (other than my attempted update at the
ReleaseTodo page a week or so ago, for example, the percentages toward
the listed goals hadn't changed in probably a month). Keeping things
up-to-date and clear about todo stuff should help a lot for 3.1, I
think. A 'release coordinator' would help a lot, too.

I know I'm responsible for a lot of the non-bugfix commits. I probably
shouldn't have commit access in any case, but I won't complain. :) I
simply find that features/updates are usually easier and more
enjoyable for me to code - writing new stuff in my own style is
preferable to fixing bugs that could be anywhere in someone else's
style. Next feature freeze, however, I'll definitely do more
bugfixing, and less of the more unimportant stuff.

On 5/30/06, Christi Alice Scarborough <christi_at_chiark.greenend.org.uk> wrote:
> I'm afraid that despite offering to shepherd this release through, I
> haven't been able to follow through on that for the usual reason (poor
> health). My regrets that that's left a void, but it's been unavoidable
> I'm afraid.
>
> Daniel Stenberg wrote:
>
> > A) drop H300 from the release and ship Rockbox 3.0 for Archos and
> > iriver H100
> > on friday.
>
> I'd have to say that I'm loathe to come out of freeze until the core
> functionality is actually bug free. A lot of the difficulty with
> current Rockbox development is that while there are many people working
> on bells and whistles, not enough coders are working on making sure the
> darn thing actually plays music reliably. There has been some lovely
> work on plugins and the UI, but it's all a bit pointless if it doesn't
> work. 3.0 is more than a release. It's a stamp of approval and a mark
> of quality.
>
> Having said that, we can't stay in freeze forever, but if we don't have
> a release quality product, there's little point in coming out of freeze.
> The moment we come out of freeze, a whole slew of new features will go
> into the source, and a slew of new bugs with them. If the current code
> is flaky, how much more flaky will post 3.0 code be?
>
> One of the really strong features of the Rockbox 2.x series has been
> that it's been stable for a long long time. Releasing 3.0 as a step
> back in stability would be a big disappointment.
>
> Having said that, I'm really not sure how to fix the issue of the fact
> that there's not enough knowledgeable people working on the code. I'm
> as guilty of this as the next coder - I'm the first to admit that the
> playback engine is voodoo to me - but I can't see myself having the time
> to devote to understanding it properly in the near term.
>
> The bottom line: if we want to release Rockbox, we need more coders
> willing and able to get to grips with both the firmware layer and the
> playback engine.
>
> Christi
>

-- 
- Zakk
midkay_at_gmail.com

Received on 2006-05-31