| 1 |
On Mon, Apr 29, 2013 at 6:27 PM, Ciaran McCreesh |
| 2 |
<ciaran.mccreesh@××××××××××.com> wrote: |
| 3 |
> What ultimately got approved by the Council, and what implementers |
| 4 |
> should be following, is the wording which ended up in PMS. |
| 5 |
> |
| 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 |
|
| 11 |
Whether this is retroactive or forward-going should be based on the |
| 12 |
practical impact of each, not on whether the council approved |
| 13 |
something without appreciating every possible ramification of the |
| 14 |
wording as-written. Specs are a communication tool - not writ from |
| 15 |
heaven. |
| 16 |
|
| 17 |
Arguing over whether we should go ahead and break a whole bunch of |
| 18 |
packages in the interim just to comply with the spec until it is fixed |
| 19 |
is basically reducing human intelligence to algorithmic behavior. |
| 20 |
There is a reason that we program the machines, and not the other way |
| 21 |
around (yet). |
| 22 |
|
| 23 |
If it really is better for our users to follow the spec as-is for now, |
| 24 |
I'm sure everybody is all ears, but I haven't seen any examples |
| 25 |
offered. The council is of course welcome to chime in if they'd |
| 26 |
rather the portage maintainers do so. |
| 27 |
|
| 28 |
This whole thing seems best chalked up to well-intending people making |
| 29 |
omissions (maybe), and the virtue of competent developers who don't |
| 30 |
just blindly follow the spec when it doesn't make sense. |
| 31 |
|
| 32 |
Sure, fix the spec, but it makes more sense to make this retroactive |
| 33 |
unless somebody can really point to something that this breaks. If |
| 34 |
the damage from doing so exceeded the damage from not doing so you |
| 35 |
probably wouldn't even need the council to get everybody to go along |
| 36 |
with you. |
| 37 |
|
| 38 |
Rich |
Archives