| 1 |
Rich Freeman posted on Mon, 29 Apr 2013 19:12:37 -0400 as excerpted: |
| 2 |
|
| 3 |
> This whole thing seems best chalked up to well-intending people making |
| 4 |
> omissions (maybe), and the virtue of competent developers who don't just |
| 5 |
> blindly follow the spec when it doesn't make sense. |
| 6 |
|
| 7 |
Actually, much as it's widely agreed there's value in porting an app to |
| 8 |
at least one other arch even if there's not enough potential users there |
| 9 |
to justify it directly, because it helps to root out and get bugs fixed |
| 10 |
that would never be found otherwise, I'd say the same applies here: |
| 11 |
|
| 12 |
There's value in someone being just contrarian enough to purposefully |
| 13 |
look for the strangest or most illogical read of a spec and (initially) |
| 14 |
implement it that way, in ordered to root out and get the bugs in the |
| 15 |
spec fixed. That said... |
| 16 |
|
| 17 |
> Sure, fix the spec, but it makes more sense to make this retroactive |
| 18 |
> unless somebody can really point to something that this breaks. |
| 19 |
|
| 20 |
Agreed. Once the bug has been demonstrated and a fix to the spec is in |
| 21 |
process, the value of a contrarian read of the existing spec has been |
| 22 |
exploited and there's no longer any value in it. Just fix it (both the |
| 23 |
spec and the contrarian implementations), as soon as possible (and |
| 24 |
possibly retroactively for the spec), which given the nature of |
| 25 |
specifications and the bureaucracy which surrounds them, will by |
| 26 |
definition tend to be sooner for the implementation than for the spec, a |
| 27 |
fix for which will take its time to work thru the bureaucracy. |
| 28 |
|
| 29 |
-- |
| 30 |
Duncan - List replies preferred. No HTML msgs. |
| 31 |
"Every nonfree program has a lord, a master -- |
| 32 |
and if you use the program, he is your master." Richard Stallman |
Archives