From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D13D2138200 for ; Mon, 29 Apr 2013 23:48:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A75B2E083E; Mon, 29 Apr 2013 23:48:23 +0000 (UTC) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 89DBEE07E2 for ; Mon, 29 Apr 2013 23:48:22 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id c13so2948049eek.33 for ; Mon, 29 Apr 2013 16:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Of+3A+N5E5Cp2sXdpFSZ44SuNRG7o4ro5nmvELtCHys=; b=dsO5BrChex6mJCSfw1aj1XDLd4UvKBmhdlbFvAC2ToKDnWerbxIfo+CotW7W7L1cQL x2zsLOpDIlC8h9Ns/yyTaPM0s87S/07mqG5A6nZV+Hi2YE2lfhz8nIp9kUHmdKuzJwnv jmWmzNrEzQROit1TXLvnEzN3pScIdWquDX01pX2FV+r1mxJhcm+qFNqXpNM86rQ56YN/ 4wITCtcib5D0kQA59KctLLCnTBCJuB1+I/2h/LFnTfNjPFuOOXNIJtA4jkK6C5v6Zv93 gKcgN67N0rC76S+VOX3KIlXM3qWoxMS6rsHZYxeyi4TdxcQOWfIg8mgWvZws4xNpO8jq qkow== X-Received: by 10.15.34.199 with SMTP id e47mr106484419eev.35.1367279301138; Mon, 29 Apr 2013 16:48:21 -0700 (PDT) Received: from [192.168.4.18] ([5.157.117.94]) by mx.google.com with ESMTPSA id k43sm35372302een.2.2013.04.29.16.48.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Apr 2013 16:48:20 -0700 (PDT) Message-ID: <517F066E.4050302@gmail.com> Date: Tue, 30 Apr 2013 01:46:54 +0200 From: "vivo75@gmail.com" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130410 Thunderbird/17.0.5 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@lists.gentoo.org CC: Rich Freeman Subject: Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation? References: <20130429075549.06e8ad66@gentoo.org> <201304291436.42577.vapier@gentoo.org> <20130429194917.46d4985c@googlemail.com> <20862.56778.599974.921136@a1i15.kph.uni-mainz.de> <20130429215950.019cd23b@googlemail.com> <20862.62111.902255.208565@a1i15.kph.uni-mainz.de> <20130429232709.6d755604@googlemail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 07c7322c-f32e-4fbf-880c-7a5d138c4f60 X-Archives-Hash: 913121bbbc9e92f9c4fe694370e4b9c6 On 04/30/13 01:12, Rich Freeman wrote: > On Mon, Apr 29, 2013 at 6:27 PM, Ciaran McCreesh > wrote: >> What ultimately got approved by the Council, and what implementers >> should be following, is the wording which ended up in PMS. >> > I can't speak for everywhere, but even in the highly regulated > environment I work in, an error in a specification is a good reason to > fix the specification, not to change the implementation. Just out of curiosity what happen in a highly regulated environment if an individual systematically try to find loopholes and use them against the environment? In production? Or to say it another way to boycott things staying in the rules, lawyers enjoy this, but programmers? > > Whether this is retroactive or forward-going should be based on the > practical impact of each, not on whether the council approved > something without appreciating every possible ramification of the > wording as-written. Specs are a communication tool - not writ from > heaven. > > Arguing over whether we should go ahead and break a whole bunch of > packages in the interim just to comply with the spec until it is fixed > is basically reducing human intelligence to algorithmic behavior. > There is a reason that we program the machines, and not the other way > around (yet). > > If it really is better for our users to follow the spec as-is for now, > I'm sure everybody is all ears, but I haven't seen any examples > offered. The council is of course welcome to chime in if they'd > rather the portage maintainers do so. > > This whole thing seems best chalked up to well-intending people making > omissions (maybe), and the virtue of competent developers who don't > just blindly follow the spec when it doesn't make sense. > > Sure, fix the spec, but it makes more sense to make this retroactive > unless somebody can really point to something that this breaks. If > the damage from doing so exceeded the damage from not doing so you > probably wouldn't even need the council to get everybody to go along > with you. > > Rich >