Hi Jonathan,

>> 1. bin increase

We're obviously going to have to agree to disagree here. You seem to think
that a 32MB buffer is lots of memory; I think of it as the most important
resource we have to keep battery life up. I don't know which device/setup
you use normally, but perhaps it's because I use a HDD player, not a flash
one? And I run off battery 90% of the time. And I've seen the buffer size
drop by about 3MB in the past 2 years...

[ Maybe "mediocre" features should only be added to flash players... ;-) ]

>> 2. settings bloat (i.e we have too many settings already)

Personally, I have no objection here (aside from binsize) - however, I do
little support work on Rockbox. At my day job, we know well that every
added option (potentially) gives another dimension to the test matrix. But
I guess it's sensible to tell people with problems to reset their settings
anyway, hence my position.

I don't like the simple/advanced menus option; if a setting is worth having,
it's worth putting in the correct place and won't be an annoyance per se.

I do think that every setting should be accessible from the menus (where
reasonable). If a feature is so unwanted or mediocre that it's implemented
as a second-class citizen then I'd question its inclusion at all.

>> 3. code maintainability

This really shouldn't be a problem at all. The code we've got needs to be
more modular, and I'd hope that as features go in (and people work on the
code), the structure would naturally improve. Maybe I'm being optimistic
again!

>> 4. The majority of users won't use the setting.

No argument for or against here - we don't have any way to measure how many
users use a setting, heck we don't really know how many users there are. Of
course, as Paul pointed out, later removal of a feature is likely to result
in a response...

Ultimately, I don't think that a general statement can be made here - it
needs to be considered on a feature-by-feature basis. But IMHO the focus of
the project should be more on stability, reliability and
usability/consistency, not just on how many features we can pack in.

pondlife
Received on 2008-10-27