On 11/13/2011 05:27 PM, Thomas Sachau wrote: > Zac Medico schrieb: >> On 11/13/2011 03:09 PM, Thomas Sachau wrote: >>> Zac Medico schrieb: >>>> On 11/13/2011 07:49 AM, Thomas Sachau wrote: >>>>> 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. >>>> >>>> Why should we expose new users to legacy defaults that are useless to >>>> more than 99% users, when they would most likely prefer the >>>> --quiet-build display? >>> >>> Why should we change the default behaviour for existing users? Those, who >>> dont want to see it, >>> probably already use --jobs or quiet-build=y. For the rest, they either >>> dont know about those >>> options (which does not get better, if some default behaviour changes) or >>> they dont want those >>> options (in which case you force them to change their >>> configuration/scripts/way to do things). >> >> When we change defaults, it affects everyone who hasn't yet overridden >> the setting in EMERGE_DEFAULT_OPTS. That's just how it is. > > So you have no problem changing the expected behaviour for the existing user, > who already got used > to the output or adjusted it themselves and might even rely on the verbose > output? Additionally i > have not seen any message from portage telling me about this change, so most > users wont know, what > changed or how to revert the change...
It's in the ebuild ChangeLog, the RELEASE-NOTES, and there's also an elog message that's triggered when upgrading from less than portage-2.1.10.34 (portage-2.2.x users won't see the elog message, of course). I think it's worth noting that there's no guarantee that a given person who sees one of these notifications will make a mental connection between the notification and the new behavior that they will observe from emerge at a later time. The time gap leaves lots of room for a lack of comprehension. > I would at least expect some longer waiting period in the "discussion" before > doing such changes or > presenting some real numbers before doing such change. Well, the initial feedback was all positive. By deploying the change, it has enabled us to gather more interest and get more feedback. >>> Additionally, do you have any numbers about existing or new users and about >>> the percentage, which >>> would like the build output to be quiet? >> >> All I have is the feedback from this mailing list, an my own intuition. >> My intuition says that --quiet-build is reasonable default that the >> silent majority of people will welcome. >> >>> Otherwise i see such lines as guess and could say the same >>> about the exact opposite view ;-) >> >> Well, my interpretation of this thread says that the response is >> overwhelmingly positive, but I could be biased. ;) > > You are obviously biased, since you prefer the quiet output. ;-) > The numbers of commenting people in here are way too low to say anything, but > there is obviously no > big majority for either side, which implies to me, that such a change should > not have been done in > the first place and should be reverted. Well, it's much easier to gather interest and get feedback if we deploy the change and ask questions later. -- Thanks, Zac
