Ah, but the battery life issue on H300 is an actual major bug, most likely,
rather than simply our software running less efficiently than it could. At
least, that seems to be the current belief. So instead of an improvement,
it's a real bug. People can still download the 3.0 source and compile for
H300, but I don't feel that we can in good conscience say that it's working
as it should, which we should be able to with a release.
On 5/30/06, Jonathan Gordon <email@example.com> 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 <firstname.lastname@example.org> 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@example.com>
> > > 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
> > > 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
> > > on bells and whistles, not enough coders are working on making sure
> > > 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
> > > of quality.
> > >
> > > Having said that, we can't stay in freeze forever, but if we don't
> > > a release quality product, there's little point in coming out of
> > > The moment we come out of freeze, a whole slew of new features will
> > > into the source, and a slew of new bugs with them. If the current
> > > 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
> > > 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
> > firstname.lastname@example.org
Received on Wed May 31 02:47:31 2006