Catching up with some old groff-list email:
On 9/16/17, Bertrand Garrigues <bertrand.garrig...@laposte.net> wrote: > I can take in charge part of the job of the maintainer: the build > system, making release; I've also studied src/roff/troff source code and > I'm planning to propose changes in `troff' to support Knuth-Plass > paragraph formating algorithm (a long-term task and of course not for > the next release). But I'm not competent for questions/bugs on macro > packages (there are currently lots of open bugs and patch requests for > macro packages) and I can't be a technical lead like Werner, I could be > at most a "co-maintainer". Does it make any sense to split groff into two packages: one that is just the base groff system, and one that is just the macro sets? I see some advantages to this: - As Bertrand points out, from a maintainership point of view, the skill sets are disjoint. Someone skilled in C/C++ code might not be as strong in groff macros, and vice versa. - The classical macro sets predate groff and are not exclusive to groff. It would be nice if there were a definitive place where the -ms macros, -me macros, etc., lived, which could be incorporated by other roff implementations. This improves upon the status quo in one of two possible ways: - for roffs such as neatroff that do not include any macro sets, this provides an easy way for users to pick up the classical sets without needing to download/install groff or another entire roff package. - for roffs such as Heirloom that currently have their own copies of these macro sets, a bug fix that is applied to, say, Heirloom's -ms macros may not get propagated to groff's version of these macros, and vice versa. Naturally, splitting out the macro sets does not guarantee that other roff projects will use them, but it does give them a reasonable way to do so. The obvious potential drawback is that we're already having trouble finding a dedicated maintainer for just the one package, so now we're doubling that problem space. But I wonder if attracting qualified maintainers would be easier if the scope of responsibility were reduced. I can think of several longtime list members who would be excellent maintainers for the macro packages but who probably don't know the first thing about the C++ code that drives groff. And Bertrand has already stated he's in the opposite camp.
