XavierGr wrote:
The phrase was a "tongue in cheek", that's what the smiley was about
in case someone was offended by it. I don't get where the problem is
with that.
Tongue in cheek or not, it creates a tone different from reasoned
discussion. That's my point: Let's keep this without the jokes or asides.
It would be interesting to see the effect on battery performance now
and when the targets where newly ported and/or how much the binsize
increased.
A more reasonable test would be battery life now vs battery life now
with RAM-eating functions removed (a build without several features
compiled in at all). In many cases battery life has gone up, or not
changed much, simply due to optimization despite increased RAM use. This
doesn't mean that the increased RAM use wasn't harmful, just that we've
compensated for it in those specific cases.
Sorry but my memory doesn't help me much. Which are these 384kb of RAM
targets? (I hope that you don't mean the iFP).
Sansa Clip. The iFP has 1MB of RAM.
I never said that, my whole point was not to be so rejecting at new
settings; not to instantly accept all of them. It is the consensus
that appears here that I try to avoid, that consensus later will be
backed up on IRC discussions and finally a rejecting policy might be
considered de-facto.
You said "all new ones should be included after making sure that they
are less complex as possible" with "ones" quite clearly being settings.
This sounds, to me, like you're advocating inclusion of all proposed
ones. But even if you're not, your proposal seems to be "if we can't
agree to reject them, we should accept them" which basically just means
you need a few vocal holdouts to include a feature that will negatively
affect the silent majority. In the case of *not* adding features, it
doesn't make Rockbox *worse* if a feature ends up getting turned down.
Adding too many mediocre features, though, undeniably makes it worse in
the general sense.
I wouldn't of course, expect the "rate" to be the same. As you say the
project has matured enough so it is rather logical to have less and
less features on the tracker.\
Again I must say that the point was not the rate, but the factor of
acceptance. If it gets too negative it will be a major drawback for
rockbox development.
Your first paragraph in the message I responded to was about a
comparison of the *rate* of acceptance when you joined vs now. I assumed
then that you felt rate was actually relevant since you made no mention
of the ration of quality features accepted vs rejected. You even went so
far to suggest that you were happy that unneeded settings were accepted.
So, frankly, I felt you were talking about rate since that was what the
introduction of your email was about.
