Gentoo Archives: gentoo-dev

From: "vivo75@×××××.com" <vivo75@×××××.com>
To: gentoo-dev@l.g.o
Cc: Rich Freeman <rich0@g.o>
Subject: Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?
Date: Mon, 29 Apr 2013 23:48:28
In Reply to: Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation? by Rich Freeman
1 On 04/30/13 01:12, Rich Freeman wrote:
2 > On Mon, Apr 29, 2013 at 6:27 PM, Ciaran McCreesh
3 > <ciaran.mccreesh@××××××××××.com> wrote:
4 >> What ultimately got approved by the Council, and what implementers
5 >> should be following, is the wording which ended up in PMS.
6 >>
7 > I can't speak for everywhere, but even in the highly regulated
8 > environment I work in, an error in a specification is a good reason to
9 > fix the specification, not to change the implementation.
10 Just out of curiosity what happen in a highly regulated environment if
11 an individual systematically try to find loopholes and use them against
12 the environment? In production?
13 Or to say it another way to boycott things staying in the rules, lawyers
14 enjoy this, but programmers?
15 </troll>
16 >
17 > Whether this is retroactive or forward-going should be based on the
18 > practical impact of each, not on whether the council approved
19 > something without appreciating every possible ramification of the
20 > wording as-written. Specs are a communication tool - not writ from
21 > heaven.
22 >
23 > Arguing over whether we should go ahead and break a whole bunch of
24 > packages in the interim just to comply with the spec until it is fixed
25 > is basically reducing human intelligence to algorithmic behavior.
26 > There is a reason that we program the machines, and not the other way
27 > around (yet).
28 >
29 > If it really is better for our users to follow the spec as-is for now,
30 > I'm sure everybody is all ears, but I haven't seen any examples
31 > offered. The council is of course welcome to chime in if they'd
32 > rather the portage maintainers do so.
33 >
34 > This whole thing seems best chalked up to well-intending people making
35 > omissions (maybe), and the virtue of competent developers who don't
36 > just blindly follow the spec when it doesn't make sense.
37 >
38 > Sure, fix the spec, but it makes more sense to make this retroactive
39 > unless somebody can really point to something that this breaks. If
40 > the damage from doing so exceeded the damage from not doing so you
41 > probably wouldn't even need the council to get everybody to go along
42 > with you.
43 >
44 > Rich
45 >