1 |
Zac Medico wrote: |
2 |
> On 11/13/2011 03:09 PM, Thomas Sachau wrote: |
3 |
>> Zac Medico schrieb: |
4 |
>>> On 11/13/2011 07:49 AM, Thomas Sachau wrote: |
5 |
>>>> Please give me a good reason, why i should by default do more things (adding quiet-build=n to the |
6 |
>>>> default emerge opts or searching for and opening the build.log) and what i or others do get from |
7 |
>>>> that. And less lines on the screen is no added value for me, it removes value. |
8 |
>>> Why should we expose new users to legacy defaults that are useless to |
9 |
>>> more than 99% users, when they would most likely prefer the |
10 |
>>> --quiet-build display? |
11 |
>> Why should we change the default behaviour for existing users? Those, who dont want to see it, |
12 |
>> probably already use --jobs or quiet-build=y. For the rest, they either dont know about those |
13 |
>> options (which does not get better, if some default behaviour changes) or they dont want those |
14 |
>> options (in which case you force them to change their configuration/scripts/way to do things). |
15 |
> When we change defaults, it affects everyone who hasn't yet overridden |
16 |
> the setting in EMERGE_DEFAULT_OPTS. That's just how it is. |
17 |
> |
18 |
>> Additionally, do you have any numbers about existing or new users and about the percentage, which |
19 |
>> would like the build output to be quiet? |
20 |
> All I have is the feedback from this mailing list, an my own intuition. |
21 |
> My intuition says that --quiet-build is reasonable default that the |
22 |
> silent majority of people will welcome. |
23 |
> |
24 |
|
25 |
Here is some feedback then. I liked it the way it was. When a build |
26 |
fails, I do a one of install of that package and I like to see the |
27 |
output. Why, because sometimes it gives me a hint as to why it failed |
28 |
or something I can google for. |
29 |
|
30 |
This is a users point of view. I expect things to remain the same |
31 |
unless that will break something. I like emerge, or any program, to |
32 |
work like it always has, at least what the user sees, until the change |
33 |
is so drastic to compel a change a user does see. |
34 |
|
35 |
So, the option to change the output that people expect to see is not |
36 |
anything that needs to be done. It doesn't change what portage does |
37 |
under the hood and there is no real reason to change it. |
38 |
|
39 |
On a side note. I do wish things like this, added features to portage, |
40 |
could be announced on something like user-announce. That would mean a |
41 |
addition mailing list but that could be read only except to devs. When |
42 |
something is going to change, announce it there. Maybe some thread on |
43 |
the forums for those who don't use mailing lists. I have noticed that |
44 |
portage is a moving target. Things are constantly being added and it is |
45 |
difficult to keep up at times. This would certainly help. The messages |
46 |
would be few but I think it would be awesome to have. When something |
47 |
gets added, send out a announcement so people know to expect it and can |
48 |
decide if it is something they can use. |
49 |
|
50 |
Hope you enjoy my feedback even tho it is different from what you |
51 |
expected. I'm rare but not that rare. |
52 |
|
53 |
Dale |
54 |
|
55 |
:-) :-) |