Re: Release policy and coordination
Very well said, Paul. I was originally in the let's just get this out of the way so we can end the freeze boat, but I've almost completely changed my mind. I think that either the H300 should remain unsupported, or the issue fixed - as Paul put it, people consider 3.0 working how it should, and when they realize that's not the way they want it to work, they're gone. I'll personally try to get things cleaned up on the bug and possibly feature-request trackers tonight, and fix a couple bugs if I have the time - I'd like 3.0 to be released ASAP, but I agree that it's not quite at the 'ready' stage at this point. If all I can really do is fix some minor stuff, that's what I'll do. :) Is there any update on the release date? We've already overshot the 4th anniversary of Rockbox 1.0. :( (BTW, I think an announcement on the front page about the 4th anniversary would be cool.) On 6/1/06, Paul Louden [EMAIL PROTECTED] wrote: I would like to state that the intent of my message was not to imply that users are lazy, stupid, or incapable. Simply that they are users. When something is stated as released it is a stamp saying this works how it is supposed to. It gives the user the implication that everything is functioning as it should, or as reasonably close as feasible. With something like freezes, a user will instantly realize either they're doing something wrong, or something wrong is with the software, and seek answers. If you tell them something is 'released' and it halves the battery life of their player, the simple assumption is 'this software draws more power'. It's Occam's Razor. It may be incorrect in this case, but the majority of users will make that assumption. In fact it's not a stupid one at all, really, but it's one that we don't want to be made. I just wanted to clarify that the mentioned view of users is definitely not why I feel the way I do. People will trust us when we release it, and to give them something like that is a betrayal of their trust. I mean, it's clearly possible to put it in large red letters on the download page, or something else, but users can also get it from their friends, or a direct link in the forum, or somewhere else entirely. We can't control the circumstances under which they receive the software, and as much as we'd like to try, we can't guarantee that they receive the proper documentation with it, or even know that the resources at rockbox.org exist. But we can avoid putting our stamp of approval on what is essentially an unfinished project. On 6/1/06, Jonathan Corbet [EMAIL PROTECTED] wrote: Andrew Hart [EMAIL PROTECTED] wrote: I agree whole heartedly with the sentiments below concerning the typical user who is too lazy, stupid or incapable of taking five minutes to read the release notes. Wow. Is that really how this project views its users? That will put off more people than the battery life issue ever could. I guess I would counter that users who cannot be bothered to read the written materials will never succeed in installing the bootloader, and thus will not be affected by the battery life problem. For the rest, a prominent note in the installation instructions should be a sufficient word to the wise. I still think that H3xx Rockbox is an improvement over the stock firmware in enough ways that it is worth making generally available. If the project would rather leave it out of the 3.0 release, it's not a huge deal, though; as has been pointed out, those of us who want it can still find it. jon -- - Zakk [EMAIL PROTECTED]
Re: Release policy and coordination
On Fri, 2 Jun 2006, Dominik Riebeling wrote: a quick idea on this: how about packaging the (still draft, but hopefully this will be better for 3.1) manual to the release fullzip archives? I totally agree that's what we should do. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Release policy and coordination
Paul Louden wrote: Most completely casual users won't even complain though. They'll try it, dislike it, and then switch back. I still very strongly feel that a known bug of that degree should not simply be a noted issue in the comments. What *strong* reson is there to include H300 in this release? The code will be there, people can use 3.0 on H300, but since it's not officially released there will be no misconception that it's fully functioning the way it should. It's a fair point. I take back my earlier statement. Christi
Re: Release policy and coordination
Andrew Hart [EMAIL PROTECTED] wrote: I agree whole heartedly with the sentiments below concerning the typical user who is too lazy, stupid or incapable of taking five minutes to read the release notes. Wow. Is that really how this project views its users? That will put off more people than the battery life issue ever could. I guess I would counter that users who cannot be bothered to read the written materials will never succeed in installing the bootloader, and thus will not be affected by the battery life problem. For the rest, a prominent note in the installation instructions should be a sufficient word to the wise. I still think that H3xx Rockbox is an improvement over the stock firmware in enough ways that it is worth making generally available. If the project would rather leave it out of the 3.0 release, it's not a huge deal, though; as has been pointed out, those of us who want it can still find it. jon
Re: Release policy and coordination
I would like to state that the intent of my message was not to imply that users are lazy, stupid, or incapable. Simply that they are users.When something is stated as released it is a stamp saying this works how it is supposed to. It gives the user the implication that everything is functioning as it should, or as reasonably close as feasible. With something like freezes, a user will instantly realize either they're doing something wrong, or something wrong is with the software, and seek answers. If you tell them something is 'released' and it halves the battery life of their player, the simple assumption is 'this software draws more power'. It's Occam's Razor. It may be incorrect in this case, but the majority of users will make that assumption. In fact it's not a stupid one at all, really, but it's one that we don't want to be made. I just wanted to clarify that the mentioned view of users is definitely not why I feel the way I do. People will trust us when we release it, and to give them something like that is a betrayal of their trust. I mean, it's clearly possible to put it in large red letters on the download page, or something else, but users can also get it from their friends, or a direct link in the forum, or somewhere else entirely. We can't control the circumstances under which they receive the software, and as much as we'd like to try, we can't guarantee that they receive the proper documentation with it, or even know that the resources at rockbox.org exist. But we can avoid putting our stamp of approval on what is essentially an unfinished project.On 6/1/06, Jonathan Corbet [EMAIL PROTECTED] wrote: Andrew Hart [EMAIL PROTECTED] wrote: I agree whole heartedly with the sentiments below concerning the typical user who is too lazy, stupid or incapable of taking five minutes to read the release notes.Wow.Is that really how this project views its users?That will putoff more people than the battery life issue ever could.I guess I would counter that users who cannot be bothered to read the written materials will never succeed in installing the bootloader, andthus will not be affected by the battery life problem.For the rest, aprominent note in the installation instructions should be a sufficient word to the wise.I still think that H3xx Rockbox is an improvement over the stockfirmware in enough ways that it is worth making generally available.Ifthe project would rather leave it out of the 3.0 release, it's not ahuge deal, though; as has been pointed out, those of us who want it canstill find it.jon
Re: Release policy and coordination
Hi, On 6/1/06, Paul Louden [EMAIL PROTECTED] wrote: like to try, we can't guarantee that they receive the proper documentation with it, or even know that the resources at rockbox.org exist. But we can avoid putting our stamp of approval on what is essentially an unfinished project. a quick idea on this: how about packaging the (still draft, but hopefully this will be better for 3.1) manual to the release fullzip archives? It could be placed in the .rockbox/doc folder, and would also give the opportunity pointing release users to that document. Also, I think the standard user (who is a _user_ and isn't interested in the development or anything more than a working player at all) is a user, meaning he wouldn't look further in the software, look for further help or anything but wipe rockbox of its player -- like Paul already wrote. Which means we need to take care he'll have a good experience. - Dominik
Re: Release policy and coordination
Hmm, apologies for the many typos there. Hopefully it still makes a bit of sense. Steve Bavin
Re: Release policy and coordination
Jonathan Gordon said: 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..) How much of an issue is battery life on the 340 anyway? I use an up-to-date daily build all the time (usually no more than a couple of days out of date) on my 340, and I easily see about 8 hours of battery life predicted, and I get through a full day's use each day, and recharge overnight. For me, the battery life is a non-issue and I use my unit a lot. It could always be improved on of course, but it's plenty good enough to release IMHO. TBH, I'm more concerned that voiced files/dirs stops after playlist completion as I use the unit a lot in the car, and voicing files is very handy to avoid distraction. -- Mike Holden
Re: Release policy and coordination
Mike Holden wrote: For me, the battery life is a non-issue and I use my unit a lot. It could always be improved on of course, but it's plenty good enough to release IMHO. If this was a question of optimization, I would agree. In this case, it is a hardware issue, where some component is drawing a lot of current, most likely because of a faulty initialization/use of the hardware. Linus
Re: Release policy and coordination
Malcolm Tyrrell wrote: ... 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? Has the possibility of maintaining seperate release branches been considered? Several times. The problem is that we most likely won't be able to handle the extra administrative work that goes with it. Linus
Re: Release policy and coordination
I still think it'd be fair to make H100 the only _new_ release target for the time being. I mean the 3.0 code will be compileable for H300, and we can even make a 3.0 binary available for it, but calling it a release is like a stamp of approval, and it just doesn't seem right (in my opinion, of course) to release it with that type of bug regardless of how little or much it impeded use. There are _many_ people waiting for it to be released for H300 to use it, and if we say this is the release version, many people will not read anything else, and when they find the battery life poor expect that we've either given up on it, or declared it impossible to improve beyond this point and give up on using Rockbox. Many users don't read information on our site, or release notes, or anything, and I feel they could very easily make the wrong assumptions or become misinformed because of this, and it's much easier to simply say 3.0 is officially for Archos targets and iRiver H1xx then when the problem is resolved, either back the solution into the 3.0 code for that one problem, or simply include H300 in whatever release is after that fix. On 5/31/06, Christi Alice Scarborough [EMAIL PROTECTED] wrote: Linus Nielsen Feltzing wrote: Mike Holden wrote: For me, the battery life is a non-issue and I use my unit a lot. It could always be improved on of course, but it's plenty good enough to release IMHO. If this was a question of optimization, I would agree. In this case, it is a hardware issue, where some component is drawing a lot of current, most likely because of a faulty initialization/use of the hardware. I have to say that I think a release without this fix in place seemsplausible to me.I think we'd need to note the outstanding issue in the release notes and download page, but it's not something that actually stops H300 Rockbox working useably, definite bug though it is. It'snot really missing functionality so much as suboptimal operation in myopinion, and while obviously it'd be better not to release without a fix, going ahead anyway might not be so terrible.Christi
Re: Release policy and coordination
wasnt the general consensus to keep the freeze going for a bit longer and really try to get ppl focused on the problems? and like has been said a million times already.. the battery issue shouldnt keep the h300 out of the release.. just put it as a known issue that is being looked into in the release notes.. then when ppl complian tell them to look there... On 01/06/06, Paul Louden [EMAIL PROTECTED] wrote: I still think it'd be fair to make H100 the only _new_ release target for the time being. I mean the 3.0 code will be compileable for H300, and we can even make a 3.0 binary available for it, but calling it a release is like a stamp of approval, and it just doesn't seem right (in my opinion, of course) to release it with that type of bug regardless of how little or much it impeded use. There are _many_ people waiting for it to be released for H300 to use it, and if we say this is the release version, many people will not read anything else, and when they find the battery life poor expect that we've either given up on it, or declared it impossible to improve beyond this point and give up on using Rockbox. Many users don't read information on our site, or release notes, or anything, and I feel they could very easily make the wrong assumptions or become misinformed because of this, and it's much easier to simply say 3.0 is officially for Archos targets and iRiver H1xx then when the problem is resolved, either back the solution into the 3.0 code for that one problem, or simply include H300 in whatever release is after that fix. On 5/31/06, Christi Alice Scarborough [EMAIL PROTECTED] wrote: Linus Nielsen Feltzing wrote: Mike Holden wrote: For me, the battery life is a non-issue and I use my unit a lot. It could always be improved on of course, but it's plenty good enough to release IMHO. If this was a question of optimization, I would agree. In this case, it is a hardware issue, where some component is drawing a lot of current, most likely because of a faulty initialization/use of the hardware. I have to say that I think a release without this fix in place seems plausible to me. I think we'd need to note the outstanding issue in the release notes and download page, but it's not something that actually stops H300 Rockbox working useably, definite bug though it is. It's not really missing functionality so much as suboptimal operation in my opinion, and while obviously it'd be better not to release without a fix, going ahead anyway might not be so terrible. Christi
Re: Release policy and coordination
Most completely casual users won't even complain though. They'll try it, dislike it, and then switch back.I still very strongly feel that a known bug of that degree should not simply be a noted issue in the comments. What *strong* reson is there to include H300 in this release? The code will be there, people can use 3.0 on H300, but since it's not officially released there will be no misconception that it's fully functioning the way it should.On 5/31/06, Jonathan Gordon [EMAIL PROTECTED] wrote:wasnt the general consensus to keep the freeze going for a bit longer and really try to get ppl focused on the problems?and like has been said a million times already.. the battery issueshouldnt keep the h300 out of the release.. just put it as a knownissue that is being looked into in the release notes.. then when ppl complian tell them to look there...On 01/06/06, Paul Louden [EMAIL PROTECTED] wrote: I still think it'd be fair to make H100 the only _new_ release target for the time being. I mean the 3.0 code will be compileable for H300, and we can even make a 3.0 binary available for it, but calling it a release is like a stamp of approval, and it just doesn't seem right (in my opinion, of course) to release it with that type of bug regardless of how little or much it impeded use. There are _many_ people waiting for it to be released for H300 to use it, and if we say this is the release version, many people will not read anything else, and when they find the battery life poor expect that we've either given up on it, or declared it impossible to improve beyond this point and give up on using Rockbox. Many users don't read information on our site, or release notes, or anything, and I feel they could very easily make the wrong assumptions or become misinformed because of this, and it's much easier to simply say 3.0 is officially for Archos targets and iRiver H1xx then when the problem is resolved, either back the solution into the 3.0 code for that one problem, or simply include H300 in whatever release is after that fix. On 5/31/06, Christi Alice Scarborough [EMAIL PROTECTED] wrote: Linus Nielsen Feltzing wrote: Mike Holden wrote: For me, the battery life is a non-issue and I use my unit a lot. It could always be improved on of course, but it's plenty good enough to release IMHO. If this was a question of optimization, I would agree. In this case, it is a hardware issue, where some component is drawing a lot of current, most likely because of a faulty initialization/use of the hardware. I have to say that I think a release without this fix in place seems plausible to me.I think we'd need to note the outstanding issue in the release notes and download page, but it's not something that actually stops H300 Rockbox working useably, definite bug though it is. It's not really missing functionality so much as suboptimal operation in my opinion, and while obviously it'd be better not to release without a fix, going ahead anyway might not be so terrible. Christi
Re: Release policy and coordination
(I must say the code lacks some comments, sometimes ;). At the moment, I'm just looking round the sources trying to understand them. Would it be useful for people like myself to submit comment patches? As I look round the code, I could add comments when I work out what something does, and submit a patch with my comments in them. Malcolm. ___ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html
RE: Release policy and coordination
On Tue, 30 May 2006, Bryn Smith wrote: Please don't take this the wrong way, but it doesn't really encourage newcomers to the project when they come across masses of uncommented code. We don't write Rockbox in order to welcome newcomers. We write Rockbox for the fun of it. We're all doing the best we can given the time we can spend. If you think of improvements to some areas, then please go ahead and improve them and submit patches. I think we all agree on that it would be great to have very well commented code with huge documentation and up-to-date descriptions of code flow and concepts. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Release policy and coordination
Bryn Smith wrote: Unfortunately most of the code I looked at had very little commenting. I was a little surprised to find that even functions weren't documented as to their purpose and none of the files even had a basic description of their function! Welcome to the world of unpaid volunteer work. :-) Hopefully, you will discover that lots of the code is fairly easy to understand even without comments. Please don't take this the wrong way, but it doesn't really encourage newcomers to the project when they come across masses of uncommented code. Perhaps not. Feel free to add comments along the way and submit a patch or two. Linus
Re: Release policy and coordination
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]
Re: Release policy and coordination
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 PROTECTED] wrote: im in the same boat as midkay.. i wouldnt mind fixing bugs if iactually could.. but most of the code is over my head..also, apart from a fwe playback issues i tinhk the current cvs isfarily stable.. and battery life shouldnt be a reason to not release for h300 (not that it really means anything to most of the pplwatching 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
bug report closing (was Re: Release policy and coordination)
On Tue, 30 May 2006, Zakk Roberts wrote: 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; My position on this: *all* bugs that have an outstanding question that needs to be answered for the bug case to move forward SHOULD be closed if nobody replies to the open question within two weeks. If the submitter happens to be legitimately away for that period, he/she can always re-open the task later or submit a new bug report. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: bug report closing (was Re: Release policy and coordination)
I agree, with the ability of anyone to close bug reports, you should be able to close them with a message like This should be fixed in CVS now. Open a new one if the bug still exists, with updated instructions on how to reproduce them with a new build. On 5/31/06, Daniel Stenberg [EMAIL PROTECTED] wrote: On Tue, 30 May 2006, Zakk Roberts wrote: 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;My position on this: *all* bugs that have an outstanding question that needs to be answered for the bug case to move forward SHOULD be closed if nobodyreplies to the open question within two weeks.If the submitter happens to be legitimately away for that period, he/she can always re-open the task later or submit a new bug report.--Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Release policy and coordination
I think one major problem is that this release bit off more than it could chew. One primary goal was to release for the H300, but to do that something that needed to be done was solve the power problem.The _problem_ being that I don't believe anyone has actually clearly identified what the problem is,. It seems to me that for a proper release to happen (say, with 3.1) all new features need to be in and functioning before the freeze (for example TagCache is still incomplete) and changes should stay focusing on fixing specific individual bugs (for example, the playback system rework should've either been held until after the freeze, or the freeze end date should've been announced as being dependent upon the results of that rework and any bugs it may create.) The main problem though is that many people, ESPECIALLY non-committers, continue working on non-release code. People still write plugins or other features. For the release perhaps the idea of a deadline/date should be dropped entirely, and a list of bugs should be collected somewhere, with the release When these bugs are resolved. Then actually request that non-committers help with those bugs too. Right now the Release ToDo is fairly vague, saying X system needs work, but not really clear on what to do, so I get the feeling that many external developers who _might_ be interested haven't got a clear idea of what to look at. And of course many others have just sorta vanished until the freeze is over. To summarize I suppose, it seems to me like there needs to be a clearer (and more finite) goal with future freezes, with a specific list of what needs to be done, if at all possible, and no feature work at all. Just my views on the whole thing, though it should of course be noted that I'm watching from outside. It's clear some of the problems that exist just _can't_ be fixed within a timeline, because you can't say We will discover the cause of this bug in the next X days. On 5/29/06, bk [EMAIL PROTECTED] wrote: Hey all,Since 3.0 didn't happen today (despite it being the proposed absolutedeadline) I think some rethinking needs to be done about releases.Obviously there's some problems to deal with, since we've been in a freeze forever, there's little CVS activity and no clear indications onwhen a release might happen, what's holding it up or who even makes thefinal decision.Maybe with how development is now working so-called 'stable' releases aren't really suitable? Would it be better to just release a CVS tarballonce every 30 days like wine used to do? The 2.x series is already outthere so we could call the new tarballs something likerockbox-3.20060531.tar.gz .Regardless of the release style I propose that something be done aboutcommunication. Let's appoint someone the title of releasecoordinator/manager who's job it is to get the devs together on aspecific date or feature goal and make sure it gets stuck to. If we promise to release on a certain date it will happen. If it doesn't, theuser/contributor community will get a specific list of reasons why and anew target date. I'm not saying the person would have dictatorial control, but instead that person would make sure that there's consensusamong the core devs and that decision making is open and transparent.bk
Re: Release policy and coordination
On Mon, 29 May 2006, bk wrote: Obviously there's some problems to deal with, since we've been in a freeze forever, there's little CVS activity and no clear indications on when a release might happen, what's holding it up or who even makes the final decision. Yes, there are too few developers actually focused on fixing the bugs and remaining issues. The majority of us all are just waiting for others to fix them so that 3.0 is released and the freeze is lifted. Personally, I say we basically are down to two options: A) drop H300 from the release and ship Rockbox 3.0 for Archos and iriver H100 on friday. B) drop the entire release and make another release attempt later on when we have sorted out the remaining playback/voice issues and possibly a few power related issues on H300. I think I favour version A here. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Release policy and coordination
My vote is for A. I was actually going to suggest that in my previous one, but tied it off and fell asleep for a while instead.If the H300 issue really is a hardware problem, or any single primary cause, the changes necessary to fix it will hopefully be able to be backed into the 3.0 code, and it can later be added to the release (just as a 3.0 on H300 release) in my opinion. Not ideal, but it'll give the H300 users something more than simply Use less buggy code with power issues, or potentially more buggy code without them. On 5/30/06, Daniel Stenberg [EMAIL PROTECTED] wrote: On Mon, 29 May 2006, bk wrote: Obviously there's some problems to deal with, since we've been in a freeze forever, there's little CVS activity and no clear indications on when a release might happen, what's holding it up or who even makes the final decision.Yes, there are too few developers actually focused on fixing the bugs andremaining issues. The majority of us all are just waiting for others to fixthem so that 3.0 is released and the freeze is lifted. Personally, I say we basically are down to two options:A) drop H300 from the release and ship Rockbox 3.0 for Archos and iriver H100 on friday.B) drop the entire release and make another release attempt later on when we have sorted out the remaining playback/voice issues and possibly a few power related issues on H300.I think I favour version A here.--Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
