comment #9:

>   I will have a shot at this.

Thanks for volunteering!

> The current difference between my branch
> and that of master is in the attachments.
>
>   Most of it is an addition to the bugs #54538, #54539,
> #55007, #55027, #55044, and #55732.

All those as clickable links: bug #54538, bug #54539, bug #55007, bug #55027, bug #55044, and bug #55732

Some of these bug reports have patches that have been reviewed by other developers, but it is not clear this feedback has been taken into account.  Bug #55044, for example, has an extensive analysis of what is wrong with its proposed patch, but that patch appears to have been applied as-is in the hdtbl.tmac.diff attachment here.

In any case, it seems unlikely a monolithic patch of the sort in the hdtbl.tmac.diff attachment will be accepted; more useful are individual changes with a log entry explaining each one's rationale.

To that end, my advice would be to focus on the individual bug reports cited above.  Address the feedback provided, either by refining the patch or refuting points made against it, until you have something that solves the identified problem in a manner acceptable to everyone.  Through this process you'll learn how to better get patches accepted -- whether this is by creating better patches, or better justifying them.

comment #4:

>   What will then replace the "fonts_n.ps" and "fonts_x.ps" files,
> which show all the characters in the fonts provided by groff?

These files being buried in contrib/hdtbl/examples means users looking for examples of the font glyphs likely won't find them.  (I was unaware of their existence until your comment.)  I see that bug #64967 seeks to remedy this.

Nonetheless, aside from these files' utility as hdtbl examples, if hdtbl is withdrawn I'm not convinced replacements for these files need to ship with groff: for users who want to see all the glyphs in a font, generating such a list or table is a fairly beginner-level groff exercise.

hdtbl has proven useful at catching bad builds in the past, so I feel it continues to have some utility (though its man page annoys me as much as its code annoys Ingo).

I don't feel much personal motivation to do anything about hdtbl.  If someone wants to go to the trouble of preparing patches and illustrating how our test coverage won't shrink (or writing compensatory tests), that could change the calculus for me.

comment #5:

> which implies his previously quoted characterization of the package as "buggy as hell" is speculative based on code inspection, rather than empirical based on testing.

Note that code review and black-box testing are both methodologies (among others that are also useful, depending on the situation) that are actively being used in the software industry for the purpose of quality assurance, and i have done both in professional capacities (i.e. being paid for doing such work).  Obviously, all methodologies have their specific strengths and weaknesses.  For example, black box testing has the advantage of working even without access to the source code, but comes at the price of being more difficult and more time-consuming.  Fuzzing has the advantage of reducing the human working time needed, but at the price of only finding some types of issues and finding bugs only in a random manner rather than systematically per-feature.  Human code review is much easier and faster than automated testing, in particular for judging the overall code quality - admittedly, it is hard to make sure that a review found all the problems, but that's not the goal here.

I think calling code review "speculative" in this context - as if systematic testing were somehow better - is not helpful.  If you already know from code review that code is of bad quality, starting a systematic testing effort would be nothing but a waste of time, unless somebody is willing to invest the large amount of time that is required for cleaning the code up.

When garbarge code is found in the tree and within three years, no one speaks up who is using it and no one speak up who wants to repair it, how long do we want to wait before throwing it out?

Isn't it a no-brainer that low-quality unmaintained code should be deleted?  I'd go as far as saying that should be done even if the code is used by a few people and even if there is no replacement.  If people want to use garbage code on an individual basis, that is their individual problem, and they can still do that if they really want to even after deletion because old versions remain publicly available, but we should not promote garbage code and encourage its use by redistributing it.

  Deprecated means in my dictionary "undesirable".

  When declared deprecated, users should stop using it and use another
(newly added) feature (command) instead.
  The next step is declaring it obsolete.

  I added diagnostic options (-ww -b) to the "groff" command (bug
#54461, 2018-08-07) in "hdtbl.am" to find out where defects could be
present, and added patches to fix those.
  I am just compiling the software.

  "hdtbl" uses the groff-machinery, so I find a close neighbourhood to
be advantageous, showing what can be done with the help of "groff".

  What makes "hdtbl" different from all the other software in the
"contrib" category?

  What will then replace the "fonts_n.ps" and "fonts_x.ps" files,
which show all the characters in the fonts provided by groff?

comment #1:

>   I see no need to abandon "hdtbl".

The proposal to deprecate it means it should exist in the next n releases of groff with notice that it's deprecated.

It's unclear how much use it gets, as every reported bug against it seems to have arisen from code inspection or build warnings, rather than from actual use of the macros, despite the fact that they're "buggy as hell" (per Ingo).  But announcing its deprecation is more likely to smoke out any actual users.

Are you generating Heidelberger tables for your own work, or merely running basic tests against the package because it's part of groff?

> This software is in the "contrib" category, those who want to use it
> are more or less on their own.

That's not the purpose of "contrib".  Per the file LICENSES: "Files in the contrib/ subdirectory of the source distribution are not strictly part of groff.  That is, they are distributed with it and are Free Software <https://www.gnu.org/philosophy/free-sw.en.html>, but they are not considered essential parts of the distribution.  Further, they may bear licenses other than the GPL or the FSF does not administer their copyrights."  There's more discussion of this in bug #59545.  (Granted, LICENSES is not an intuitive place to look for this info.  A README or similar in "contrib" itself might be useful.)

If users are "more or less on their own," probably the appropriate place for that code is in a source repository separate from groff's.  Groff declining to distribute it doesn't mean no one else can.

In bug #54461, one developer characterizes hdtbl as "totally unmaintained" and another says "If the component is totally unmaintained then we should drop it from the groff distribution."

Bug #55044 throws further shade on this macro package: "The low code quality of the hdtbl macros is really annoying, they are buggy as hell."