Re: Release policy and coordination

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

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 <paulthenerd <at> gmail.com> 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 <christi <at> chiark.greenend.org.uk>
> 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

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

Flyspray abuse..?

Please could somebody with the ability consider closing bug #5471 -
http://www.rockbox.org/tracker/task/5471

IMHO this is a support query, not a bug report and should be redirected to
the forum, user mailing list or IRC.  There are already plenty of support
channels (too many?) and there is no advantage to tolerating the use of
Flyspray for this.

Steve Bavin

Re: Release policy and coordination

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.  In addition, Rockbox has built up 
a respectable name and image for itself, despite its development just 
being done mostly for fun by the various developers.  The core devs 
and everybody involved in the Rockbox project should be able to take 
justifiable pride in what has been acheved with Rockbox.  It would be 
a shame to lose this image simply because something is stamp 
"official release" before it is truly ready.

Imho, battery life is an issue.  The stock standard firmware can run 
the Iriver H340 for 14 to 20 hours playing music, depending on the 
format and bit rate, etc.  I haven't done a proper battery test with 
Rockbox, but Rockbox seems to run my unit for only 5-6 hours 
typically.  This will preclude the use of Rockbox for long flights.

Given that on all the Archos platforms and the Iriver IHP 1xx series 
players, Rockbox usually runs significantly more efficiently than the 
stock standard firmware, it seems likely that the power consumption 
issue is a definite bug, probably hardware-based as has been pointed 
out by others on this list, and in my opinion this ought to be fixed 
before the H300 receives endorsement from the Rockbox crew as an 
officially supported player.

Cheers,
Andrew.

At 22:19 31-05-2006, you 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 
><<mailto:christi <at> chiark.greenend.org.uk>christi <at> chiark.greenend.org.uk> 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

Andrew Hart <ahart <at> dim.uchile.cl> 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

wpsbuild.pl

Hi,

to get multi-target wps' into CVS a change of the wpsbuild.pl script,
and possibly also the arrangement of the WPSLIST file is necessary.
The problem as it is now, is that we can not include the same wps for
several targets if that wps uses different fonts for the different
targets. What are the thoughts on this? What would be the proper
approach to make this possible? Keep a WPSLIST file for each of the
resolutions is a solution. I.e.

wpsname/resolutionxbpp/WPSLIST

The font used for that resolution would then be defined in the WPSLIST-file.
Reason for sending this mail is because I think we have agreed that
iCatcher should be committed (and shipped as default theme for the
upcoming release?).

Martin

Re: Release policy and coordination