1 |
Amadeusz Żołnowski schrieb: |
2 |
> Excerpts from Thomas Sachau's message of 2011-11-13 14:59:57 +0100: |
3 |
>> How is that an argument for default quiet build? It is exactly the |
4 |
>> same argument against default quiet build. If someone does not care, |
5 |
>> he does not care about the output being verbose or not, so no need to |
6 |
>> change a default for him. |
7 |
> |
8 |
> As I have written below, information about overall process is more |
9 |
> valuable than some gmake rubbish (to the user) output which slows down |
10 |
> build time. And having that shinny human readable output gives actually |
11 |
> an information to the reader. |
12 |
> |
13 |
> |
14 |
>> And what does a number of users knowing about an option have to do |
15 |
>> with a default setting? |
16 |
> |
17 |
> More user-friendly options should be default, not developer-friendly. |
18 |
> The discussion started with problem, that build.log could be more |
19 |
> verbose, which will clutter users' screen even more. |
20 |
|
21 |
And you do define, what is user-friendly and what not? :-) |
22 |
|
23 |
Remember, that every developer is also a user. And i hope, you dont define user-friendlyness the |
24 |
same way as some say about gnome upstream: the less the user gets or sees, the more user friendly |
25 |
the application will be. |
26 |
While the quiet-build setting suppresses everything, the verbose output does not harm me (more lines |
27 |
dont reduce the time i can use that screen or anything similar), but it can tell me something about |
28 |
the actual build process (even if it is only some basics like "still doing the time-consuming |
29 |
confiure phase, still compiling, currently at linking stage, for some packages even more detailed). |
30 |
|
31 |
Please give me a good reason, why i should by default do more things (adding quiet-build=n to the |
32 |
default emerge opts or searching for and opening the build.log) and what i or others do get from |
33 |
that. And less lines on the screen is no added value for me, it removes value. |
34 |
|
35 |
> |
36 |
> |
37 |
>> You expect people to manually check the build.log just to see, where |
38 |
>> it hangs? I prefer checking the console, there i can see it directly |
39 |
>> and dont have to check for the path of the current build.log and then |
40 |
>> have to additionally open it manually. So your "no harm" is plain |
41 |
>> wrong, since it takes me more time for doing the same thing as before, |
42 |
>> while i still see no benefit for the change of the default. |
43 |
> |
44 |
> If you need to watch build output, change defaults. Defaults are for |
45 |
> less experienced users, not for us developers or power users. |
46 |
|
47 |
I disagree. Defaults should not be for a specific user group, they should be adding most possible |
48 |
values without doing harm. Otherwise everyone could see a different user group as target and see |
49 |
himself as right without any chance for a consensus. |
50 |
|
51 |
> |
52 |
> |
53 |
>>> But --quiet-build=y actually gives more useful and handy info: what |
54 |
>>> is a total progress. Which user cares about which module is |
55 |
>>> actually being compiled? He/she cares more which package out of |
56 |
>>> total is being compiled at the moment. |
57 |
>> |
58 |
>> If someone does not care about the current state of a compile, he wont |
59 |
>> care about the total state either. |
60 |
> |
61 |
> Build output hardly ever says about current state of a compile. If you |
62 |
> can tell from the output how much is left for example for firefox - |
63 |
> respect. |
64 |
|
65 |
So you can get anything from "build 8 of 124" or "build 1 of 2"? This is similar to verbose build |
66 |
output: It could tell you, which package currently is compiled, but you dont get any specific |
67 |
details like "How long until finished?" or "How much more time until finished?", since even the last |
68 |
remaining package could require 99% of total build/install time. |
69 |
So if you like details about total state, why do you want to hide the state of the current compile? |
70 |
|
71 |
> |
72 |
> |
73 |
>> Beside the point, that you can see the total state in the terminal bar |
74 |
>> (i hope, i got the right name for that thing). |
75 |
> |
76 |
> This not always work. |
77 |
|
78 |
Sure, you can work inside a screen without such a bar. So in such a case, you dont have any detail |
79 |
from this feature. But do you ignore such a feature, just because some people might not be able or |
80 |
willing to see it? And do you want to replace other output a user can get by this one just to be |
81 |
sure everyone gets this by default? |
82 |
|
83 |
|
84 |
I have 2 additional questions: |
85 |
|
86 |
1. Who defines, what the default should be and when it is acceptable to force an unknown amount of |
87 |
users to change their settings? |
88 |
|
89 |
2. Since this change is obviously controversal now, will it be reverted or do the people arguing |
90 |
against the change have to somehow force a revert or proove it being less good than the previous |
91 |
default (also thinking about how such a proove could be done) to get the new behaviour changed or |
92 |
reverted? |