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