|
Rockbox mail archiveSubject: Re: Release policy and coordinationRe: Release policy and coordination
From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Wed, 31 May 2006 09:47:25 +1000 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 <midkay_at_gmail.com> 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 <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 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |