Amadeusz Żołnowski schrieb:
> Excerpts from Thomas Sachau's message of 2011-11-13 14:59:57 +0100:
>> How is that an argument for default quiet build? It is exactly the
>> same argument against default quiet build. If someone does not care,
>> he does not care about the output being verbose or not, so no need to
>> change a default for him.
> 
> As I have written below, information about overall process is more
> valuable than some gmake rubbish (to the user) output which slows down
> build time.  And having that shinny human readable output gives actually
> an information to the reader.
> 
> 
>> And what does a number of users knowing about an option have to do
>> with a default setting?
> 
> More user-friendly options should be default, not developer-friendly.
> The discussion started with problem, that build.log could be more
> verbose, which will clutter users' screen even more.

And you do define, what is user-friendly and what not? :-)

Remember, that every developer is also a user. And i hope, you dont define user-friendlyness the
same way as some say about gnome upstream: the less the user gets or sees, the more user friendly
the application will be.
While the quiet-build setting suppresses everything, the verbose output does not harm me (more lines
dont reduce the time i can use that screen or anything similar), but it can tell me something about
the actual build process (even if it is only some basics like "still doing the time-consuming
confiure phase, still compiling, currently at linking stage, for some packages even more detailed).

Please give me a good reason, why i should by default do more things (adding quiet-build=n to the
default emerge opts or searching for and opening the build.log) and what i or others do get from
that. And less lines on the screen is no added value for me, it removes value.

> 
> 
>> You expect people to manually check the build.log just to see, where
>> it hangs? I prefer checking the console, there i can see it directly
>> and dont have to check for the path of the current build.log and then
>> have to additionally open it manually. So your "no harm" is plain
>> wrong, since it takes me more time for doing the same thing as before,
>> while i still see no benefit for the change of the default.
> 
> If you need to watch build output, change defaults.  Defaults are for
> less experienced users, not for us developers or power users.

I disagree. Defaults should not be for a specific user group, they should be adding most possible
values without doing harm. Otherwise everyone could see a different user group as target and see
himself as right without any chance for a consensus.

> 
> 
>>> But --quiet-build=y actually gives more useful and handy info: what
>>> is a total progress.  Which user cares about which module is
>>> actually being compiled?  He/she cares more which package out of
>>> total is being compiled at the moment.
>>
>> If someone does not care about the current state of a compile, he wont
>> care about the total state either.
> 
> Build output hardly ever says about current state of a compile.  If you
> can tell from the output how much is left for example for firefox -
> respect.

So you can get anything from "build 8 of 124" or "build 1 of 2"? This is similar to verbose build
output: It could tell you, which package currently is compiled, but you dont get any specific
details like "How long until finished?" or "How much more time until finished?", since even the last
remaining package could require 99% of total build/install time.
So if you like details about total state, why do you want to hide the state of the current compile?

> 
> 
>> Beside the point, that you can see the total state in the terminal bar
>> (i hope, i got the right name for that thing).
> 
> This not always work.

Sure, you can work inside a screen without such a bar. So in such a case, you dont have any detail
from this feature. But do you ignore such a feature, just because some people might not be able or
willing to see it? And do you want to replace other output a user can get by this one just to be
sure everyone gets this by default?


I have 2 additional questions:

1. Who defines, what the default should be and when it is acceptable to force an unknown amount of
users to change their settings?

2. Since this change is obviously controversal now, will it be reverted or do the people arguing
against the change have to somehow force a revert or proove it being less good than the previous
default (also thinking about how such a proove could be done) to get the new behaviour changed or
reverted?