From: Thomas Martitz <thomas47_at_arcor.de>
Date: Tue, 28 Oct 2008 18:40:22 +0100

Jonathan Gordon schrieb:
> none of these have a working patch yet, and yes there will be argument
> if/when they ever are ready.
>
Depends on you define as working. They all have a working patch, but if
their committability is another question (and I quite like how my custom
list patch works).

I pretty much agree with XavierGr in this discussion. Devs tend to
evaluate new features only on their own using habbits. More then often
binsize seems (to me) just to be brought up as a reason since it's the
standard reason and sounds very much better than "I won't use the
feature, so it won't get in, especially not if I'd have to look at an
option more in the setting".

I don't say binsize isn't a valid reason. But it's kinda stressed very
much lately, even for quite small additions. In fact, it helps stalling
the developement. Why should one contribute if he doesn't have any hope
to get behind the binsize wall. And the more features are rejected (or
just rotting further) for binsize reasons the higher the wall seems to be.

I do however say that we should evaluate settings before they get in.
Unlike to the features (I like new features very much) I'm very
sensitive to settings bloat. I'm really in favor of picking sane
defaults most people can live with (this goes for FS#9455 as well). And
with sane defaults, new features one doesn't want to use are not
noticable if unwanted, i.e. let the user focus on the features he likes
while being perfectly able to ignore the ones he doesn't like.

We then could possibly just have a features setting menu, where you can
chose from several features to be enabled or disabled. This way, unused
features could free most of the RAM they "waste" reducing the ram usage
impact. And once you have set those features, you've hardly visit the
feature setting again and doesn't have to fea the settings bloat.
Received on 2008-10-28