From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RPcKN-0004xl-Tv for garchives@archives.gentoo.org; Sun, 13 Nov 2011 15:50:40 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2678821C059; Sun, 13 Nov 2011 15:50:31 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D0C6621C02C for ; Sun, 13 Nov 2011 15:50:04 +0000 (UTC) Received: from [192.168.178.22] (p548D32B6.dip.t-dialin.net [84.141.50.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tommy) by smtp.gentoo.org (Postfix) with ESMTPSA id 6F54B1B400D for ; Sun, 13 Nov 2011 15:50:02 +0000 (UTC) Message-ID: <4EBFE727.8000903@gentoo.org> Date: Sun, 13 Nov 2011 16:49:59 +0100 From: Thomas Sachau User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20111108 Firefox/7.0.1 SeaMonkey/2.4.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev Subject: Re: [gentoo-dev] have portage be quiet by default References: <4EB4FA98.3080201@gentoo.org> <4EBD42EE.4060104@gentoo.org> <4EBEF208.5060500@gentoo.org> <201111121840.16686.vapier@gentoo.org> <4EBFBA75.3030500@gentoo.org> <1321188262-sup-4513@raeviah> <4EBFCD5D.3080807@gentoo.org> <1321194595-sup-8983@raeviah> In-Reply-To: <1321194595-sup-8983@raeviah> X-Enigmail-Version: 1.3.3 OpenPGP: id=211CA2D4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA083824784A17DFD9B48DAD7" X-Archives-Salt: 64dc62fa-7edb-4fbb-b73f-bc2fb44ae29d X-Archives-Hash: e1b5246b7239cd48034e909e68c922b9 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA083824784A17DFD9B48DAD7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Amadeusz =C5=BBo=C5=82nowski schrieb: > Excerpts from Thomas Sachau's message of 2011-11-13 14:59:57 +0100: >> How is that an argument for default quiet build? It is exactly the >> same argument against default quiet build. If someone does not care, >> he does not care about the output being verbose or not, so no need to >> change a default for him. >=20 > As I have written below, information about overall process is more > valuable than some gmake rubbish (to the user) output which slows down > build time. And having that shinny human readable output gives actuall= y > an information to the reader. >=20 >=20 >> And what does a number of users knowing about an option have to do >> with a default setting? >=20 > More user-friendly options should be default, not developer-friendly. > The discussion started with problem, that build.log could be more > verbose, which will clutter users' screen even more. And you do define, what is user-friendly and what not? :-) Remember, that every developer is also a user. And i hope, you dont defin= e user-friendlyness the same way as some say about gnome upstream: the less the user gets or sees= , the more user friendly the application will be. While the quiet-build setting suppresses everything, the verbose output d= oes not harm me (more lines dont reduce the time i can use that screen or anything similar), but it c= an tell me something about the actual build process (even if it is only some basics like "still doin= g the time-consuming confiure phase, still compiling, currently at linking stage, for some pac= kages even more detailed). Please give me a good reason, why i should by default do more things (add= ing quiet-build=3Dn 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 v= alue. >=20 >=20 >> You expect people to manually check the build.log just to see, where >> it hangs? I prefer checking the console, there i can see it directly >> and dont have to check for the path of the current build.log and then >> have to additionally open it manually. So your "no harm" is plain >> wrong, since it takes me more time for doing the same thing as before,= >> while i still see no benefit for the change of the default. >=20 > If you need to watch build output, change defaults. Defaults are for > less experienced users, not for us developers or power users. I disagree. Defaults should not be for a specific user group, they should= be adding most possible values without doing harm. Otherwise everyone could see a different user = group as target and see himself as right without any chance for a consensus. >=20 >=20 >>> But --quiet-build=3Dy actually gives more useful and handy info: what= >>> is a total progress. Which user cares about which module is >>> actually being compiled? He/she cares more which package out of >>> total is being compiled at the moment. >> >> If someone does not care about the current state of a compile, he wont= >> care about the total state either. >=20 > Build output hardly ever says about current state of a compile. If you= > can tell from the output how much is left for example for firefox - > respect. So you can get anything from "build 8 of 124" or "build 1 of 2"? This is = similar to verbose build output: It could tell you, which package currently is compiled, but you d= ont get any specific details like "How long until finished?" or "How much more time until fini= shed?", since even the last remaining package could require 99% of total build/install time. So if you like details about total state, why do you want to hide the sta= te of the current compile? >=20 >=20 >> Beside the point, that you can see the total state in the terminal bar= >> (i hope, i got the right name for that thing). >=20 > This not always work. Sure, you can work inside a screen without such a bar. So in such a case,= you dont have any detail from this feature. But do you ignore such a feature, just because some pe= ople might not be able or willing to see it? And do you want to replace other output a user can get= by this one just to be sure everyone gets this by default? I have 2 additional questions: 1. Who defines, what the default should be and when it is acceptable to f= orce an unknown amount of users to change their settings? 2. Since this change is obviously controversal now, will it be reverted o= r do the people arguing against the change have to somehow force a revert or proove it being less= good than the previous default (also thinking about how such a proove could be done) to get the = new behaviour changed or reverted? --------------enigA083824784A17DFD9B48DAD7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAk6/5ycACgkQG7kqcTWJkGfrxgP+Lmlu4sKDWxeoH5DCnA9MjgKr H0vGRDmMTS/FIpsa33U5+5X4fWEcCRnPt3qgrYIODx0Uu5mbrUPJB6KxbrXLsK4E E9e1Fo9FAqcwumWBUCqV6UL51W3UaH/JWQ1dW67JUJAW0A5iZ6MLb8J9be0P/YPB onWSe4I9+Y2lObBEFac= =jvac -----END PGP SIGNATURE----- --------------enigA083824784A17DFD9B48DAD7--