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 1RXYYx-00056I-Ik for garchives@archives.gentoo.org; Mon, 05 Dec 2011 13:26:31 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 507D321C04A; Mon, 5 Dec 2011 13:26:15 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 3906921C036 for ; Mon, 5 Dec 2011 13:25:59 +0000 (UTC) Received: by bkbzu5 with SMTP id zu5so5723992bkb.40 for ; Mon, 05 Dec 2011 05:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=trQytPNQqPMJzZi7Nc+94BBANvU8f8Pw62s/rgEkx+8=; b=MWjwYMigBE2OCuDgKzPavH55GHOlPfAjPvp9wHeqQlnpU+yKfXiAbrlZY2sD6ZgHwO Nmex8mTbRYR5c2JvB2E2WViQvoE4V7qWDh5mGqypGKQ3cpCneqQySKw5kxq9qe1JmU+p l803d1CWHYuW+ML6aWCwvDF8sLkj6BHqQwBhE= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.156.220 with SMTP id y28mr4566224bkw.22.1323091559216; Mon, 05 Dec 2011 05:25:59 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.204.121.2 with HTTP; Mon, 5 Dec 2011 05:25:59 -0800 (PST) In-Reply-To: <4EDC4093.6060109@gentoo.org> References: <20111203103024.GN37825@gentoo.org> <4EDB80F8.1090800@gentoo.org> <20111204152254.GE780@gentoo.org> <4EDB94E2.8090007@gentoo.org> <4EDB9F31.9020601@gentoo.org> <4EDC29DE.3000905@gentoo.org> <4EDC358A.3070808@gentoo.org> <4EDC4093.6060109@gentoo.org> Date: Mon, 5 Dec 2011 08:25:59 -0500 X-Google-Sender-Auth: GEwF4T9jDKpEWGfnUns7mOfqMi0 Message-ID: Subject: Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13 From: Rich Freeman To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: dc380463-510e-4964-b3ca-e3a9f1a7e5d6 X-Archives-Hash: 1a6ee47de51ffb56f38af7bebcd2849e 2011/12/4 Ch=C3=AD-Thanh Christopher Nguy=E1=BB=85n : > Among the people preferring to see build output, making -v control the > default seems to be considered an acceptable compromise. So wouldn't > that be great? Hiding build output by default, while still satisfying > most critics of this idea. I don't care that strongly about the defaults since I can change them (though I'd like them to be reasonably sane so that people take us seriously). However, making -v control the output seems like a problem, unless there is some way to undo this. A typical workflow for me is to run emerge -auDNv world to see what is going to build, and then hitting enter to accept it. I want to get the verbose USE info with -a/p, but I don't really care to see build logs flying across the screen. So, overloading a single flag to do both sounds problematic unless you also allow the quiet flag to override it back. That seems complicated to me. That raises another portage flags issue - the fact that we need so many options to do "the right thing." Now, I'll argue the right thing is subjective so we do need to be able to control it. However, it seems like we should be able to agree on the best setting for general-purpose updates is, and make that a single setting. As far as opinions vs facts go - in software design the only real facts are whether a particular design satisfies or does not satisfy a particular requirements specification, or dry measures like benchmarks/scalability/etc. Whether a particular design is "better" is always a matter of opinion, unless better simply means satisfying more requirements or some other objective measure. That then just begets the question as to whether one set of requirements is better than another, and that is just vodoo. Actually, even stating as a "fact" whether a program even meets a requirement is extraordinarily difficult for all but the most trivial programs - you can't even prove conclusively whether the program will always terminate short of exhaustively testing all possible input. That's why we could perpetuate this thread for six months and never really resolve the issue, and ultimately sometimes you just need a council to weigh in with their opinion, when everybody can't live with the maintainer's opinion. Rich