On 5/30/06,
Jonathan Gordon <[EMAIL PROTECTED]> wrote:
im in the same boat as midkay.. i wouldnt mind fixing bugs if i
actually could.. but most of the code is over my head..
also, apart from a fwe playback issues i tinhk the current cvs is
farily stable.. and battery life shouldnt be a reason to not release
for h300 (not that it really means anything to most of the ppl
watching this list..)
On 31/05/06, Zakk Roberts <[EMAIL PROTECTED]> wrote:
> 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]
>
