Jonathan Gordon wrote:
1. bin increase
Well, As civil as I'd like to be, I think everyone knows my views on
this argument… Its nonsense. What's the point of the project if every
time a red delta happens everyone complains? May as well close up shop
here.
And you've heard dozens of times it's not *just* bin increase that's a
problem, but whether a feature's bin increase is worth the functionality
it adds. There's a finite limit on how much can and should be added
(though we've not set a target maximum binsize there's lowmem targets
already showing up anyway) if every feature that shows up is added,
we're eventually going to have a binary that nearly everyone will agree
is too big, and have to decide if we want to remove existing features.
Better to keep mediocre features out in the first place, rather than
having to remove features later.
2. Settings bloat.
Yes, we have lots of settings (168 in the e200 sim) but why is this
bad? If you don't change a setting and are happy with the default then
good for you, your config.cfg will be a lot smaller than someone who
does change a lot more settings. When was a decision made to make
rockbox only for the common person? The whole point of rockbox is for
people who want to customise and use their DAP the way *they* want to,
not the way someone else wants to impose on them.
There's a difference between "having a powerful set of options" and
"having the ability to configure everything you could imagine wanting to
configure, plus some."
3. code maintainability
Meh, a non-argument. You can't argue that adding a setting will make
global_settings or settings_list.c any *worse* than it already is. And
I would argue that "blaa = global_settings.my_setting_value" is easier
to maintain/understand than "blaa = 15" especially if that happens in
a few places. Besides, I'd like to think that the guys who are adding
assembly to the code are smart enough to handle a struct access…
It's not usually about the setting itself, but whatever functional code
it activates. Many suggested settings where this is objected are things
like additional playback modes, etc, where there is a real
maintainability problem. I'd be surprised if anyone's objecting to the
maintainability of the struct itself.
4. The majority of users won't use the setting.
Well, this is sort of the same as point 2, but I thing that should be
added is that until we add the setting AND setup a website so people
can submit their config.cfg files for statistics, we will never know
how many people use what.
But we can know how many people in the past have requested such a
setting, or felt the lack of that setting is a legitimate problem.
The problem seems to be distinguishing between "bloat" and "legitimate
bin increase." In my experience, your opinion is "if someone wants it,
it's not bloat" and I think that's far too liberal. I think that every
suggestion of a new feature needs justification. One shouldn't see
"people demand that I justify the binary usage" as "no feature should
ever go in" but simply "binary IS valuable, and we need to make sure
ever feature tries to use as little as possible, and ever feature that
does get in is one we valuable enough that it we won't be considering
removing it later for something else." That, generally, means a feature
needs to do something that can't be achieved another way. For example,
there's a legitimate argument that we could just compromise on the
spacing value rather than making it accept a configurable string.
Whether you agree that that's an acceptable way or not, it would mean a
lesser bin increase, no added menu option, and no setting someone will
debate removing later if we do run into binsize maximums.
Now, at some point a decision needs to be made about every feature, but
the idea that every single one should at least be challenged and
justified shouldn't be thrown out.
