On Mon, Apr 29, 2013 at 6:27 PM, Ciaran McCreesh <ciaran.mccre...@googlemail.com> 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. 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
