On 04/30/13 01:12, Rich Freeman wrote:
> On Mon, Apr 29, 2013 at 6:27 PM, Ciaran McCreesh
> <[email protected]> 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?
</troll>
>
> 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
>
