From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Mon, 27 Oct 2008 17:04:47 +1100

2008/10/27 Paul Louden <paulthenerd_at_gmail.com>:
> Jonathan Gordon wrote:
> 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.

bin size is the single biggest objection always. Sure there will
always be the people that feel a feature isnt "worth" the addition,
and there is people who feel it is.. why is it ALWAYS the first group
who "win"? worrying about low mem targets is silly. We already have a
mechanism to disable features if they just wont fit, and considering
there is 5 (6?) targets which are considered lowmem, and 20+ which are
not, why should it be harder for the vast majority to have features
they want? the answer to both groups is to build your own version. Its
easier to keep a #if BLAA disabling patch in sync than a feature
addition patch, and more people would be using the 2nd.

As for mediocre features... of course they are the only ones being
argued. "Amazing" features go in once every blue moon (going by
MajorChanges, I can count < 5 which would be considered for this group
in the last 12 months). "Shit" features are usually rejected without
any objection. Mediocre ones are the only ones where there is any
contention... But if everyone is happy with adding a feature every 2
months, well....

> 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."

Tomato, tomato... a setting you consider excessive I consider
required, and vice versa.
>
>> 3. code maintainability
> 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.

no no, I'm talking about where the actual setting is the reason for
this argument. I'm not talking about a setting which causes
maintenance issues in code which has few people are activly looking
after (like playback)


> 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.
>

Again, that only shows people who have the idea and care enough to ask
for it (or happen to ask in a place where it gets seen), that doesn't
give any indication to how many would use the setting once it was in
place.

>
> and we need to make sure ever feature tries to use as
> little as possible,
Which many of the vocal objectors deem to be 0.

> 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.

who is to say another way wont be worse? Would a version which is
written in assembly and uses half the bin/ram size be better than a C
version which anyone can maintain be better? When there are more than
one legitimate way to do something, and someone provides a patch doing
it one way, why should it be rejected by someone who isn't going to
put in the effort to do it the other 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.

Actually no, A simple strcat would be about as simple as it could be.
strcat()-ing a static string is just as "bad/wasteful" as strcat()-ing
a user string. The adding of the setting is meaningless when it comes
to the delta.

> 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.
>

Challenged? OK, justified? No, I don't think so. Unless you loosen
your definition of "justify" to include the sentence "I and others
want it, we have put in the effort, it conforms to code standards and
yes, I believe this will benefit the project."

I don't want to get personal, but 80+ people have been given the
privilege/right to change the code as they see fit, sure there is a
level of trust going both ways that it wont be abused and that commits
will benefit the community, but really, there has never been
discussion about changing the authoritative structure to something
less democratic, so in reality, commit discussions are a courtesy. The
rockbox commit offer email only says if you feel uncertain about a
commit to bring it up. I dislike "drive-by-commits" as much as anyone,
but there is a line. I guess now is as good a time as any to bring up
the usual problem where people will ignore discussion and then
complain after commit. But anyway, This is not the topic...
Received on 2008-10-27