Follow-up Comment #17, bug #67992 (group groff): [comment #11 comment #11:] > neither of you articulate a limiting principle to what you > characterize as "regression"
I don't think these various debates come down to a difference in the
definition of regression, but a difference of opinion in what is expected
behavior. The roff field is a fertile one for such debates because the
language is so inexactly specified.
All Eric Allman had to do was write "A -me macro must be invoked before any
text appears" in his -me manual, and most of this debate goes away. But he
didn't, so we're left to wonder: is it because it never occurred to him that
one might put output in a document _without_ first calling a macro? Or is it
because that's simply not a requirement? And we're left to trawl historical
texts and try to infer intent. (This situation is nothing like reading
ancient religious texts. Never in the history of ever have two people read
the same passage of a sacred text and come to vastly different conclusions
about what it means.)
So even if we all agree on a definition of regression like "When code that
used to work correctly now fails," there's still a world of grey in that word
"correctly." We have an origin document (CSTR #54) that left a lot of
language aspects under- and unspecified, and an origin implementation that
cannot be said to be bug-free because no nontrivial software is bug-free.
Then we have a re-implementation with its own bugs, and its documentation with
its own ambiguities, that has now enjoyed a longer history than its
progenitor. That confluence of inertia and slop prevents drawing neat lines
around "correct behavior," especially the more we wander into weird corner
cases. I think each of these cases has to be considered on its individual
merits, which is horribly unsatisfying to your precision-seeking mind but is
clearly what God intended, as any plain reading of 1 Corinthians 11:19 will
tell you.
> hence my Plan 9 troff SIGFPE example,
I don't remember this, and couldn't find it in the list archives or in
Savannah--and that signal name is a pretty unique search term.
> Where documentation doesn't support his rigidity,
> he points to the implementation as a specification from which
> no deviation should be permitted; see bug #63544.
I probably lean more toward your side in that particular debate, but I also
sympathize with the view that when dealing with an absent or ambiguous
specification, an implementation that's remained consistent for decades might
be as close as you can get to a specification.
> Slapping the label "regression" on anything is not an argument.
Certainly not. Obviously I can speak for neither Ingo nor Deri, but I don't
use the label as an argument, but as a factor to consider when assigning
priority to a(n alleged) bug. It can also perhaps bolster the argument that
something _is_ a bug: "The program does this, and it should do that" is a
question that can be argued; "The program does this, and it should--and used
to--do that" gives more weight to the "should" part, though I agree it doesn't
make it automatic, else nothing about the program could ever change, and we
could all put down our keyboards and take up macramé.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67992>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
