Re: [groff] [Groff] Next release - maintainership

[Dave Kemper]

Catching up with some old groff-list email:


On 9/16/17, Bertrand Garrigues <address@hidden> 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.