Releasing groff 1.22.5?

[G. Branden Robinson]

We have a formal expression of interest in a new release.

https://savannah.gnu.org/bugs/?59216

Bertrand, do you think you will be available to serve as release
engineer, or do we need to solicit interest in the role?

If anyone feels we haven't yet satisfied some technical goal that we
should have accomplished before branding something "1.22.5", please
speak up now.  I have some things I'd like to accomplish before a
release[1], but based on my experience with groff 1.22.4, I don't think
they'd interfere a beta or release-candidate cycle.

As far as I know, the tree is in pretty good shape.  I've learned to
"make distcheck", but my development machine is pretty vanilla--x86-64
running a Debian-based distro.

I feel conflicted out (as in a "conflict of interest") of casting a vote
for a release, as I wrote all of the NEWS items to date for what would
constitute 1.22.5, and this leaves me feeling like I've sucked up all
the development oxygen.

What do people think?

Regards,
Branden

[1] My list of things I'd prefer to get accomplished before a 1.22.5
"final" is something like this:

A. Fix #59106.  mdoc doesn't emit a partially-collected output line
   before switching to the next file.
B. Implement CT and CS register support (from groff_man(7)) in our mdoc.
C. Kill off our ditroff(7) page.
D. Rename an-old to an-std, since it implements the de facto standard
   man macros from Version 7 Unix (1979).  "-old" implies that the
   implementation is legacy, and while I'm sure mdoc fans feel that way,
   it's not reflective of affairs in Linux.  It could alternatively
   imply that an-old is not actively maintained, as doc-old isn't, but I
   reckon I'm actively maintaining our man(7) implementation.
E. Deprecate the .OP man(7) macro and stop using it in our own pages.
   It's not actually a GNU extension, but one of _many_ extensions (some
   ill-conceived) from Documenter's Workbench 3.3 (or earlier).  It does
   nothing that can't be achieved with two-font macros and doesn't
   support GNU-style long options, so is insufficiently adaptable to
   real-world contemporary systems.
F. Fix the problem with man(7) .SY macros and HTML output.
G. Decide whether it's worth implementing .MR for man(7) after Plan 9
   just to "get it out there", or wait until I've learned enough about
   devtags to give it a full implementation that will produce links in
   PDF and HTML output.  The cheaper implementation would simply be a
   semantic wrapper around a two-font macro.  The font for the page name
   would be in a user-configurable string (like HF is today), so people
   will stop having arguments over whether the cross-references should
   be in bold or italic.
H. Integrate my pending "introduction to roff concepts" which I have in
   progress as a rewrite of the first section of the "gtroff Reference"
   chapter of our Texinfo manual.  It's my intention to adapt this
   material to serve as a conceptual introduction in roff(7) and
   groff_man_style(7) as well.  Right now it is written as an
   introduction for readers who want to go straight to "raw" troff
   without knowing much or anything about existing macro packages, but
   my opinion at the moment is that fairly little needs to be changed
   for the aforementioned adaptations.  I'm attaching the
   work-in-progress for the curious.  Feedback welcome.
I. Get the ms.ms document current at _least_ with what's in our Texinfo
   manual, and preferably with our actual ms implementation, and drop
   that chapter from our Texinfo manual as discussed some months ago.
J. Regenerate the AFM metrics and add this step to our FOR-RELEASE
   document.  Also figure out if we should be using/embedding URW font
   metrics instead.  Funny things happen when I try to draw boxes around
   some glyphs in Times roman and I think it's because the metrics are
   wrong.
K. Maybe #58796.  This is actual development work, so might not make it.

signature.asc
Description: PGP signature