Should portage hide build output from the user by default?

[avx]

Yes, I'm aware of that and I don't care about it, since I'm personally for the quieting. But if you look through this forum, quite a few threads have popped up regarding this "problem" since this people didn't read/understand it. That's why I thought, once portage is updated to this version, make it so that people notice it, i.e. halt everything else till the user presses a key or something.

[zmedico]

Yes, I'm aware of that and I don't care about it, since I'm personally for the quieting. But if you look through this forum, quite a few threads have popped up regarding this "problem" since this people didn't read/understand it. That's why I thought, once portage is updated to this version, make it so that people notice it, i.e. halt everything else till the user presses a key or something.

Oh, I see. I think it would be an overreaction to make the update interactive. I think it should be enough if we send an announcement to the gentoo-announce mailing list, and a GLEP 42 news item before the change goes to stable.

[avx]

I think it should be enough if we send an announcement to the gentoo-announce mailing list, and a GLEP 42 news item before the change goes to stable.

No, imho it's not. I don't believe that many people are reading this mailinglist - at least not those who are creating threads for this topic and a quick glance over this forum shows, it's the same with the 'news' - not even taking into account, that one can disable the news-feature.

I mean, look at this thread, >90% of posters here are regulars or even devs, but the ones opening the threads aren't. Giving some kind of interactive response is sure to reach anybody who's updating his/her system and it's imho not that intrusive - can also be delayed till the end of a merge/update, thus not stopping the process.

Again, I don't care how it's done, but I do care that non-regular forum/mailinglist readers get properly notified, it's just a simple one-time check-function for a dev to write, but it'll notify almost anybody and has the potential to spare us all some work if we don't have to answer such threads over and over again.

[zmedico]

I think it should be enough if we send an announcement to the gentoo-announce mailing list, and a GLEP 42 news item before the change goes to stable.

No, imho it's not. I don't believe that many people are reading this mailinglist - at least not those who are creating threads for this topic and a quick glance over this forum shows, it's the same with the 'news' - not even taking into account, that one can disable the news-feature.

I think a GLEP 42 news item fulfills our obligation to communicate with users well enough. Users who disable news should be fully aware that they may miss some potentially useful information if they do so.

I mean, look at this thread, >90% of posters here are regulars or even devs, but the ones opening the threads aren't. Giving some kind of interactive response is sure to reach anybody who's updating his/her system and it's imho not that intrusive - can also be delayed till the end of a merge/update, thus not stopping the process.

I see your point, but I don't think it's worth the effort. I think a GLEP 42 news item will work well enough.

Again, I don't care how it's done, but I do care that non-regular forum/mailinglist readers get properly notified, it's just a simple one-time check-function for a dev to write, but it'll notify almost anybody and has the potential to spare us all some work if we don't have to answer such threads over and over again.

I don't think it's worth having special purpose code for this. GLEP 42 news items are designed for this kind of notification.

[krinn]

I think throwing an elog message would touch more users.
The funny part is that the message will tell them they will not see any message after that one
(ok ok, setting the quite=n...)

[zmedico]

I think throwing an elog message would touch more users.
The funny part is that the message will tell them they will not see any message after that one
(ok ok, setting the quite=n...)

The elog messages are displayed by the elog echo module which is enabled by the default PORTAGE_ELOG_SYSTEM="save_summary echo" setting, regardless of --quiet-build.

[john.newman]

I think could almost be GUI like on the console.. something like this maybe

# emerge some-pkg1 some-pkg2
[
display some header info about the batch
/ packages / build env etc here
]
Building package 1 of 2:
Stage 1 of 4: [./configure] compile test install

Build output:
[

keep this area as some sort of child frame where the verbose output just slides up



]
0 [========[/]stage progress.......] 100
0 [===== package progress.............]
0 [==batch progress........................]

now i'm not expecting that from anyone of course... and after posting it i'm not even sure if i want that ... really it's fine the way it is, i just put -v in EMERGE-DEFAULT-OPTS

[Randy Andy]

Hi Zac.
I thought Gentoo is a community driven Distribution, so why you don't listen to the voice of the users as they vote here, like a democracy decision.

Ok, you dev's couldn't discuss every little decision with the whole community and must take some decisions in smaller circles to come to an result.
For me it looks like you, and some more dev's has taken the decision, to change the old standard output, cause it doesn't give you any advantage and that my be correct from your point of view, the view of a developer who is familiar with every little detail of this outstanding distro.

Honestly, reasons are much more valuable to me than votes. I am paying attention to all of the reasons that are posted here.

Ok, so here are some more:

- The old output behavior exist now for a period of 12 Years!
I make a bet, that during this time, there were no such a exclamation like this, to change this noisy and completely useless standard output to a quiet one!
But wait, if you want (please not) until the quiet output becomes standard for the stable version of portage. I'm pretty sure you'll see much more threads like this.

- In my opinion it is the special taste of Gentoo which belongs to this distro as meat to a good barbecue
- We are all grown up with it, and it learns us a lot (at least me), how compiling works, step by step.
- At first time using this distro, we're wondered at it. During the time of using portage, we learnt to understand whats going on, later we learnt to love it and how to use it.
- Don't hold back this learning process from new users. So let it stay as default setting.
- The acceptance of long waiting for compiling packages grows, if you see how much busy your PC is. This improves he acceptance for source based distro, like Gentoo.

-Otherwise every binary knowing distro-user wonders, how long it need to install packages on this distro, cause the precess looks similar to e.g. any apt-get installing progress.

- Every user who is nerved from it's noisy output, could switch it off, if he want, with the help of the well documented quiet=y option.

Although in newer times, with powerful processors, where the lines flow extremely fast, and was mixed up cause parallel threading, i could catch often some details which let me know what's the actual state of compiling, especially in a x-terminal with a long scroll buffer.
Than I'm able to hold on the output for a while, when I'm interested in a special line of the output, until the buffer is full (e.g. a short error description of a failed package, its name, the short error description and where to find the build log and the path to the build environment, or files which have a collision).

Mostely time enough for me, to mark these interestingly sections with the mouse cursor, paste it in a second x-terminal, to analyze it and to begin fixing and rebuilding these failed packages, while compiling on terminal one goes on, cause it has been started with the keep-going option which makes sense for me, especially it it's a big bunch of packages.

- I predict a decreasing rate in new users, which would be caught by gentoo, as you

still think that the vast majority would prefer to have the quiet behavior by default.

The old default was totally unnecessary for what I estimate to be greater than 99% of users. It was ridiculous, leading to jokes like apt-gentoo.

Unecessary - No, not at all and not from the beginning. Lately, when they have more experience eventually, but then they can switch it off.
Although when they attest it now, where were their objection in the past 12 Years, to change it, he. On the opposite you see a reaction comes directly, which should show you to bite the bullet and to change your decision.
By the way, this apt-gentoo side blow is 8 years old and is as unimportant if it were actual for us, and shouldn't lead anyone to a decisions, at least a developer who should know it better.

All in all it makes much more sense to hold on the old output strategy as to change it.
In my opinion, changing these traditional standard behavior is a risk for the reputation and the future of gentoo.
So don't trifle with it cause it could be more important as we can imagine from our point of few, cause we are all biased.

Regards, Andy.

[zmedico]

I thought Gentoo is a community driven Distribution, so why you don't listen to the voice of the users as they vote here, like a democracy decision.

As discussed earlier in the thread, voting is only fair when you can get a reasonably unbiased sample of the whole population. Due to human nature, people who are unhappy with the change in defaults are more likely to express their opinion publicly than people who welcome the change in defaults. This tends to bias statistics in favor of the unhappy people.

[pappy_mcfae]

At last, I have my noise back, and the internet...at least until the weather gets bad again. Please say you won't be messing with that function anymore.

Cheers,
Pappy

[John R. Graham]

I thought Gentoo is a community driven Distribution...

I actually think it's pretty clear that Gentoo is a developer driven distribution. I don't see anything in the official documentation that says anything specific about the role of the community in Gentoo's direction.

- John

[aidanjt]

I picked option 3. Frivolous printing can slow down compilation, especially with an unaccelerated framebuffer like KMS or uvesafb, and normal UNIX behaviour is to print pointless noise only when -v is explicitly defined.

[broken_chaos]

I voted show by default (i.e., status quo). Since I doubt there's any way to implement a 'progress bar' without completely re-tooling every package's buildsystem, it's nice to have the output as some measure of progress, especially on long compiles. If it were to change, it would probably have some serious effects on bug reporting -- such as how many lines of the failed build output, plus the emerge errors, would be emitted to still provide halfway decent bug reports by default.

The existence of an option to suppress the build output might want to be a little more obviously documented, though, such as in make.conf.example near EMERGE_DEFAULT_OPTS? I imagine many people didn't even realize it existed. I know I didn't.

[zmedico]

I voted show by default (i.e., status quo). Since I doubt there's any way to implement a 'progress bar' without completely re-tooling every package's buildsystem, it's nice to have the output as some measure of progress, especially on long compiles. If it were to change, it would probably have some serious effects on bug reporting -- such as how many lines of the failed build output, plus the emerge errors, would be emitted to still provide halfway decent bug reports by default.

In order to show more progress information, I've heard suggestions to show which ebuild phases are being executed. I'm not sure how many people would use an interface like that in practice, but I wouldn't be opposed to adding support for something like that. Since I'm not really interested in using an interface like that myself, so I don't feel inspired to implement it myself.

The existence of an option to suppress the build output might want to be a little more obviously documented, though, such as in make.conf.example near EMERGE_DEFAULT_OPTS? I imagine many people didn't even realize it existed. I know I didn't.

Well, people won't be able to ignore it anymore, once they upgrade to a version of portage that has --quiet-build enabled by default (>sys-apps/portage-2.1.10.34). I'm planning to send out a GLEP 42 news item before the change goes to stable, since that's the best way that we have to notify users of changes like this.

[cach0rr0]

I picked option 3. Frivolous printing can slow down compilation, especially with an unaccelerated framebuffer like KMS or uvesafb, and normal UNIX behaviour is to print pointless noise only when -v is explicitly defined.

that was my preference as well. As it is, verbose is not very verbose at akk. But I can live with it being changed, as it's a cosmetic rather than functional feature, and I have a path to revert.

Well, people won't be able to ignore it anymore, once they upgrade to a version of portage that has --quiet-build enabled by default (>sys-apps/portage-2.1.10.34). I'm planning to send out a GLEP 42 news item before the change goes to stable, since that's the best way that we have to notify users of changes like this.

as long as there are fairly clearly visible things letting people know of the change, since it's a cosmetic one I don't see a problem with it.

I run ~arch and didn't see a news item (I'm not complaining, btw, this happens when you run ~arch! - your message(s) above explain why). All of a sudden my next merge was all dolled up, threw me for a bit of a loop.
One bit worth noting when you do the news item, is not only "we're changing the behaviour", but some brief snippet that tells people what to set up in make.conf to revert to the old. I had to poke around a bit, as I didn't even know this option existed.

[krinn]

I thought Gentoo is a community driven Distribution, so why you don't listen to the voice of the users as they vote here, like a democracy decision.

As discussed earlier in the thread, voting is only fair when you can get a reasonably unbiased sample of the whole population. Due to human nature, people who are unhappy with the change in defaults are more likely to express their opinion publicly than people who welcome the change in defaults. This tends to bias statistics in favor of the unhappy people.

You doesn't really accept any arguments zac, you've just dismiss his whole thread by replying the same argument against the vote system.

This is just a part of his thread, if you re-read it, you will see he try to show new user and gentoo might be afffect, and current users won't. Let's resume it to that quote :

I predict a decreasing rate in new users

I admit i'm not sure as Andy gentoo will lost users, but i'm sure that new default will impact new users, and as him, i think it could impact badly them, and so, badly the distro. I, Andy and many have shown you why this new default is dangerous for new user, and you only show that this new default will be good for the distro as a less joke against it or a better asthetic.

Because it's sad to see you seems to take it too personal, and that as we must again & again expose the same arguments as they just seems ignore, we could hurt you doing that, while in fact everyone respect the hard and good job you've put for years in portage.

I think it's Council task to think about it and decide what should be done, and not just keep it on your shoulders.

[th9]

Most of this thread is ridiculous, considering that the issue is really insignificant.

Those opposed to the change really have presented only three arguments at best - one is that new users should see the output to get a better understanding and appreciation of what emerge is doing, some kind of progress indication and the third is pure sentiment.

If you are so sentimental, then you probably have used Gentoo for long enough to find your way to make.conf.

And new users probably will come with new machines. Now, considering the speed of modern hardware, it is arguably actually better to hide the build output from new users by default, because it would be thrown at them at such a speed, that they gain absolutely nothing but confusion. Even more so if the build systems are made verbose by default. Even more, if we consider parallel fetch and parallel make (not even considering parallel emerge), then we have already lost most of the educational value in having new users subjected to this.

Another issue is to have multiple verbosity levels for emerge for progress indication. But here it is arguably better left to other tools (I'm using htop anyway if I want to see what is going on on my machine) since it might not be trivial and this alone is not enough for keeping it default. Maybe the interactivity feature could be considered which would allow to toogle the state of quiet build option during the merge. That would give people an option to peek under the hood of emerge easily.

I would prefer emerge/portage to implement more significant features, like true multilib/cross compilation and git support, improve parallel emerge, and not waste too much time on cosmetics. One thing which might be considered is printing out elog messages on the fly. For some that might give a better sense of what emerge is at. I actually like the idea of consistent -v (the same as now), -vv (print elog messages as they come) and -vvv (print full build output).

It would be useful feature for elog echo to print only warnings, errors, qa messages and the like, but not info messages.

I could argue with Zac's position about the votes, but he made himself clear, fine. But being concerned about some joke really is even more ridiculous than the joke itself and it should never had been used to argue for nor against the change.

Defaults should be such that they minimize the amount of work to set up new system. If most of the users are expected to silence build for daily use, then that is enough to make quiet build default.

And I expect most users would do so, because it:
- improves speed on slow terminals and remote hosts
- gives better idea of how far emerge is gotten in terms of packages
- doesn't give any info which was not asked, nor needed
- doesn't confuse by trowing huge amounts of cryptic text in arbitrary order and great speed
- can be easily changed when need to see how particular package is doing
- is more consistent with other command line tools

Quiet build option should really be mentioned more in docs even if this change wouldn't come. Please, at least add it to the emerge -h output and handbook so users are aware of it even if they don't read trough all of the man page. In any case ~ARCH users are in no position to complain because something suddenly changed, that is the nature of that configuration and you have been warned. Besides that news item is enough to inform users. Some blog post or other message that shows up on the homepage also would be helpful.

The hardware and software has changed a great deal in last 10 years, so it makes perfect sense now to reconsider default behavior of emerge. And I for one welcome the change.


----
EMERGE_DEFAULT_OPTS="-av --quiet-build --complete-graph --with-bdeps=y --autounmask-write"

[zmedico]

I thought Gentoo is a community driven Distribution, so why you don't listen to the voice of the users as they vote here, like a democracy decision.

As discussed earlier in the thread, voting is only fair when you can get a reasonably unbiased sample of the whole population. Due to human nature, people who are unhappy with the change in defaults are more likely to express their opinion publicly than people who welcome the change in defaults. This tends to bias statistics in favor of the unhappy people.

You doesn't really accept any arguments zac, you've just dismiss his whole thread by replying the same argument against the vote system..

I am taking all of your reasons into account. That fact that your reasons haven't changed my decision doesn't mean that I dismiss your reasons. It just means that your reasons haven't been strong enough, in my mind, to override the opposing reasons. When judges consider a controversial case, they weigh the reasons that support or detract from each side, and that's what I'm trying to do.

This is just a part of his thread, if you re-read it, you will see he try to show new user and gentoo might be afffect, and current users won't. Let's resume it to that quote :

I predict a decreasing rate in new users

I admit i'm not sure as Andy gentoo will lost users, but i'm sure that new default will impact new users, and as him, i think it could impact badly them, and so, badly the distro. I, Andy and many have shown you why this new default is dangerous for new user, and you only show that this new default will be good for the distro as a less joke against it or a better asthetic.

I don't understand what's dangerous about the new quiet default. Can you explain?

Because it's sad to see you seems to take it too personal, and that as we must again & again expose the same arguments as they just seems ignore, we could hurt you doing that, while in fact everyone respect the hard and good job you've put for years in portage.

Being the person who committed the change, it sometimes seems as though people blame me for it, as if I acted alone. I don't think it's fair for people to blame me, as if I'm the sole person responsible for the change, because I didn't act in isolation. The change was originally suggested by Mike Frysinger, and initial feedback in that thread was 100% positive. I accept responsibility for committing the change, but I can't take full credit for it since it was suggested to me and encouraged by others.

I think it's Council task to think about it and decide what should be done, and not just keep it on your shoulders.

That is a possibility. Some others as have suggested it as well.

But being concerned about some joke really is even more ridiculous than the joke itself and it should never had been used to argue for nor against the change.

I've never said that I was concerned about the joke. My point was that apt-gentoo shows that people think that it is ridiculous to have build output shown by default, and I happen to agree with them.

Quiet build option should really be mentioned more in docs even if this change wouldn't come. Please, at least add it to the emerge -h output and handbook so users are aware of it even if they don't read trough all of the man page.

Okay, as you've suggested, I've added it to the emerge --help output. I'm planning to send out a GLEP 42 news item before the change goes to stable, since that's the best way that we have to notify users of changes like this.

[firephoto]

The apt-gentoo thing just shows other devs from other distros like making jokes about other distros. Kind of like setting up dedicated websites whose only purpose is to mock Gentoo. Or the usual comment about from people who tell you how the install goes when it finishes next week.

The most serious change this has brought is that this is probably the first major change that will require a lot of users to add an EMERGE_DEFAULT_OPTS= entry in their make.conf. If you look at a lot of the comments in favor of this change you'll also notice that a lot of these people already use this entry for other settings.

I don't necessary agree with the change but after some thinking I like the way the change came about and I hope that sensible and brief consensus can be pointed out when other changes to the project come about to prevent bikeshedding with vaguely covered "technical" excuses because something someone doesn't like might get some attention officially. It's that kind of crap that really hurts Gentoo.

I saw another comment about Gentoo being for devs more than users and while I can't disagree, this belief mostly comes from all the hoops left to jump through to get a sane default point and click desktop. Totally off topic, and not pointed at anyone here even, but if all the devs would quit hating on the other things they don't even use and putting up virtual road blocks at times and letting non-project devs steer the project Gentoo.

There are a few of us that don't develop software, that don't do consulting, that don't do vim, so don't forget us and all the other non-gentoo users that could some day be a gentoo users.

[John R. Graham]

...
I saw another comment about Gentoo being for devs more than users...

I think that was me, [post=6877248]here,[/post] and that's not quite what I said or meant to imply. In response to Randy Andy's contention that Gentoo is community-driven, I countered that I believed that it is not, and that it is pretty clear to me that Gentoo is developer-driven.

Just one example, not chosen at random. Consider the Gentoo Social Contract. It states that it's based on Debian's Social Contract. Gentoo's is, "...generally very similar to it [Debian's] except that certain parts have been clarified and augmented while other parts deemed redundant have been removed." However, one paragraph from Debian's is conspicuously absent from Gentoo's:

Our priorities are our users and free software
We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system.

I think it's nice that we get asked from time to time. I just don't think it's reasonable to expect that we always sway the developers' opinions. In fact, personally, I don't want Gentoo to be a democracy; I'd much rather it be a meritocracy and I beleve that, mostly, it is.

Now that doesn't mean that I believe that Gentoo isn't for users. I think it is, and I think, for what it is, it does a great job.

- John

[Nerdanel]

I think apt-gentoo is really making a joke about how slow compiling from the source is. Maybe apt-gentoo 0.0.2 will default to calculating the time spent stalling the progress of the installation based on the number of lines in the compilation output while printing nothing of interest... unless the user finds the correct obscure option to add to the configuration file and writes it there without typos, that is.

Gentoo is the distro of my choice because I want to be in control of my computer. I don't think Gentoo should hide information from the user, especially not by default. GCC generates those messages for a reason. More importantly, cmake generates those messages for a reason. I'm getting the feeling that the people who made the decision to change the defaults were Gnome users. I haven't made the math, but maybe half my compile time I get percentage progress indications from cmake and most of the rest are tiny programs that zip by, frequently showing which number I'm at.

With the new portage defaults I get percentage progress indications from NOTHING. Seeing where numerically I am on the list of packages to be merged isn't that useful, since packages aren't made equal (and portage in the hide-everything mode doesn't tell if I'm near the beginning or the end of a big package). Writing "emerge -p --resume" in another terminal is anyway my favored way of checking how much high-level progress there is still to be made. It shows me the names of the remaining packages too, and based on whether they are the likes of kdebase-meta or pykde4 (the latter of which is happily no longer part of my system) I can see at a glance if I'm near the end or not. And if I'm unfamiliar with the packages I can just pipe into genlop for an estimate, but I rarely bother with that.

Since joke programs seem to be so effective at spurring portage developers, perhaps I should create a program that makes fun of how emerge -p normally outputs to stdout but if there's one tiny problem with an use flag that needs to be changed it outputs the whole thing to stderr instead, just to make things difficult for people who want to pipe that output to grep, less, or something like that.

[zmedico]

Gentoo is the distro of my choice because I want to be in control of my computer. I don't think Gentoo should hide information from the user, especially not by default. GCC generates those messages for a reason. More importantly, cmake generates those messages for a reason. I'm getting the feeling that the people who made the decision to change the defaults were Gnome users. I haven't made the math, but maybe half my compile time I get percentage progress indications from cmake and most of the rest are tiny programs that zip by, frequently showing which number I'm at.

With the new portage defaults I get percentage progress indications from NOTHING. Seeing where numerically I am on the list of packages to be merged isn't that useful, since packages aren't made equal (and portage in the hide-everything mode doesn't tell if I'm near the beginning or the end of a big package). Writing "emerge -p --resume" in another terminal is anyway my favored way of checking how much high-level progress there is still to be made. It shows me the names of the remaining packages too, and based on whether they are the likes of kdebase-meta or pykde4 (the latter of which is happily no longer part of my system) I can see at a glance if I'm near the end or not. And if I'm unfamiliar with the packages I can just pipe into genlop for an estimate, but I rarely bother with that.

In case you didn't know, you can change it back to the old default like this:

Code: Select all

echo "EMERGE_DEFAULT_OPTS="\${EMERGE_DEFAUT_OPTS} --quiet-build=n"" >> /etc/make.conf

Also, note that the elog system is capable of collecting some GCC warnings for you. Warnings that are known to be dangerous will trigger a QA Notice, and you can have those message saved and displayed for you if you do this:

Code: Select all

echo "PORTAGE_ELOG_CLASSES="\${PORTAGE_ELOG_CLASSES} qa"" >> /etc/make.conf

Then the elog echo module, which is enabled by the default PORTAGE_ELOG_SYSTEM="save_summary echo" setting, will automatically display those GCC warnings just before emerge exits.

Since joke programs seem to be so effective at spurring portage developers

The joke didn't really play a role in my decision making process. I only cited apt-gentoo as evidence that people think that the old default is ridiculous. The change was originally suggested by Mike Frysinger, and initial feedback in that thread was 100% positive.

[disi]

The joke didn't really play a role in my decision making process. I only cited apt-gentoo as evidence that people think that the old default is ridiculous. The change was originally suggested by Mike Frysinger, and initial feedback in that thread was 100% positive.

There were two devs thinking out load to make it the default option, how is that 100% positive feedback (just before the s*itstorm kicked in)

//edit: the main argument was, that it is easy to turn the vebose output on again...

[Nerdanel]

I've already added myself EMERGE_DEFAULT_OPTS to make.conf to reverse the new default. I just think I shouldn't have needed to do so. I originally wrote that as EMERGE_DEFAULT_OPS and had to spend a few wasted minutes finding the typo when in a sensible world I and the rest of the apparent majority wouldn't have needed to bother with such fiddly stuff to please the minority.

Didn't someone just say that the people who approved the change already had EMERGE_DEFAULT_OPTS set?

I originally switched to Gentoo from Mandrake because Mandrake was so information-hidey and hand-holdy I wasn't learning anything about Linux after a while. If the current default had been the default then I'm sure my first impression would have been far more negative whether I figured out about EMERGE_DEFAULT_OPTS or not.

[zmedico]

The joke didn't really play a role in my decision making process. I only cited apt-gentoo as evidence that people think that the old default is ridiculous. The change was originally suggested by Mike Frysinger, and initial feedback in that thread was 100% positive.

There were two devs thinking out load to make it the default option, how is that 100% positive feedback (just before the s*itstorm kicked in)

As discussed earlier in the thread, due to human nature, people who are unhappy with the change in defaults are more likely to express their opinion publicly than people who welcome the change in defaults. This tends to bias statistics in favor of the unhappy people.

I've already added myself EMERGE_DEFAULT_OPTS to make.conf to reverse the new default. I just think I shouldn't have needed to do so. I originally wrote that as EMERGE_DEFAULT_OPS and had to spend a few wasted minutes finding the typo when in a sensible world I and the rest of the apparent majority wouldn't have needed to bother with such fiddly stuff to please the minority.

As discussed earlier in the thread, it can be difficult or impossible to get a reasonably unbiased sample of the a large population like the Gentoo users. That makes it difficult or impossible to gather statistics with confidence that they accurately reflect the preferences of the majority.