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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
