| 1 |
On 11/13/2011 05:27 PM, Thomas Sachau wrote: |
| 2 |
> Zac Medico schrieb: |
| 3 |
>> On 11/13/2011 03:09 PM, Thomas Sachau wrote: |
| 4 |
>>> Zac Medico schrieb: |
| 5 |
>>>> On 11/13/2011 07:49 AM, Thomas Sachau wrote: |
| 6 |
>>>>> Please give me a good reason, why i should by default do more things (adding quiet-build=n to the |
| 7 |
>>>>> default emerge opts or searching for and opening the build.log) and what i or others do get from |
| 8 |
>>>>> that. And less lines on the screen is no added value for me, it removes value. |
| 9 |
>>>> |
| 10 |
>>>> Why should we expose new users to legacy defaults that are useless to |
| 11 |
>>>> more than 99% users, when they would most likely prefer the |
| 12 |
>>>> --quiet-build display? |
| 13 |
>>> |
| 14 |
>>> Why should we change the default behaviour for existing users? Those, who dont want to see it, |
| 15 |
>>> probably already use --jobs or quiet-build=y. For the rest, they either dont know about those |
| 16 |
>>> options (which does not get better, if some default behaviour changes) or they dont want those |
| 17 |
>>> options (in which case you force them to change their configuration/scripts/way to do things). |
| 18 |
>> |
| 19 |
>> When we change defaults, it affects everyone who hasn't yet overridden |
| 20 |
>> the setting in EMERGE_DEFAULT_OPTS. That's just how it is. |
| 21 |
> |
| 22 |
> So you have no problem changing the expected behaviour for the existing user, who already got used |
| 23 |
> to the output or adjusted it themselves and might even rely on the verbose output? Additionally i |
| 24 |
> have not seen any message from portage telling me about this change, so most users wont know, what |
| 25 |
> changed or how to revert the change... |
| 26 |
|
| 27 |
It's in the ebuild ChangeLog, the RELEASE-NOTES, and there's also an |
| 28 |
elog message that's triggered when upgrading from less than |
| 29 |
portage-2.1.10.34 (portage-2.2.x users won't see the elog message, of |
| 30 |
course). |
| 31 |
|
| 32 |
I think it's worth noting that there's no guarantee that a given person |
| 33 |
who sees one of these notifications will make a mental connection |
| 34 |
between the notification and the new behavior that they will observe |
| 35 |
from emerge at a later time. The time gap leaves lots of room for a lack |
| 36 |
of comprehension. |
| 37 |
|
| 38 |
> I would at least expect some longer waiting period in the "discussion" before doing such changes or |
| 39 |
> presenting some real numbers before doing such change. |
| 40 |
|
| 41 |
Well, the initial feedback was all positive. By deploying the change, it |
| 42 |
has enabled us to gather more interest and get more feedback. |
| 43 |
|
| 44 |
>>> Additionally, do you have any numbers about existing or new users and about the percentage, which |
| 45 |
>>> would like the build output to be quiet? |
| 46 |
>> |
| 47 |
>> All I have is the feedback from this mailing list, an my own intuition. |
| 48 |
>> My intuition says that --quiet-build is reasonable default that the |
| 49 |
>> silent majority of people will welcome. |
| 50 |
>> |
| 51 |
>>> Otherwise i see such lines as guess and could say the same |
| 52 |
>>> about the exact opposite view ;-) |
| 53 |
>> |
| 54 |
>> Well, my interpretation of this thread says that the response is |
| 55 |
>> overwhelmingly positive, but I could be biased. ;) |
| 56 |
> |
| 57 |
> You are obviously biased, since you prefer the quiet output. ;-) |
| 58 |
> The numbers of commenting people in here are way too low to say anything, but there is obviously no |
| 59 |
> big majority for either side, which implies to me, that such a change should not have been done in |
| 60 |
> the first place and should be reverted. |
| 61 |
|
| 62 |
Well, it's much easier to gather interest and get feedback if we deploy |
| 63 |
the change and ask questions later. |
| 64 |
-- |
| 65 |
Thanks, |
| 66 |
Zac |
Archives