Re: Regressions in UTP document (was: removing the .IX macro from the ms package in 1.23 breaks old documents)

[Dave Kemper]

On Fri, Oct 4, 2024 at 2:21 PM G. Branden Robinson
<g.branden.robinson@gmail.com> wrote:
> At 2024-10-04T16:41:19+0100, Deri wrote:
> > I am certainly not against changes to groff, but I do think when we do
> > alter groff in some way which will affect the typesetting of existing
> > documents
>
> ...which the font warning change wasn't...
>
> > it is good manners to deprecate the change before making it an error
> > which will alter the way the document appears.
>
> If you were to say that some grief might have been avoided if groff
> 1.23.0 had included a banner at the top of its NEWS entry/release notes

While I agree with Branden that notices of new warnings doesn't
require any special heads-up--a well-crafted warning should speak for
itself[1]--I think Deri's general point stands: it's a courtesy to
notify users that things will go away before they actually go away.
(By this I mean notification to users of an official release, not just
to those who follow this list and/or the savannah bug tracker.)

This is the point of ticket http://savannah.gnu.org/bugs/?62916.  As
it notes, groffer went away without warning in 1.23, catching people
who don't follow this list off guard.  Groff 1.24 will lose EBCDIC
support.  Sure, any modern EBCDIC users should have seen the writing
on the wall for decades, but I predict it'll still perturb some small
number of users who don't follow groff development.

I strongly support(ed) both those items' removal.  Removing support
for EBCDIC, in particular, must be a huge maintenance win by ripping
out a lot of code complexity.  Groffer, in contrast, was a standalone
program with no shared code; it could have been allowed to languish
indefinitely, its only maintenance burden being a few minutes to make
it emit a warning that it was deprecated, then a few more minutes down
the road to remove it from the source tree.

My intent here isn't to hindsight-quarterback that decision, but to
seek ways to avoid similar pitfalls in future releases.

[1] When a warning is emitted over 1000 times, though, it's fair to
ask whether the user made the same faux pas 1000 times in the
document, or whether a lot of those instances are squawking about the
same thing.