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

[Ingo Schwarze]

Hi,

Dave Kemper wrote on Wed, Feb 21, 2018 at 02:26:15PM -0500:

> 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 don't think it makes much sense.  You can hardly use *roff without
macros (well, there are rumours about a few people using their very
own, personal macro sets, but that's certainly the exception rather
than the rule), and the macros almost unusable without groff.  To
provide just one example, i don't think that the groff_mdoc(7)
macros would stand any chance of working with any other groff
implementation.  They may heavy use of groff-specific post-1.17
features.

> - 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.

I would have been quite an inconvenient situation for the mdoc rewrite
by Werner Lemberg and Ruslan Ermilov in the past.  It would have
required to first make a groff release, wait so time and hope that
people upgrade, then release the macros using the new features.
And no doubt so people would have tried using the new amcros with
an old groff release, with bad results.  Version management is
certainly easier, both for users and maintainers, when you distribute
the macros together with a version they actually work with.

> - The classical macro sets predate groff and are not exclusive to
> groff.

If some groff macro set works with some other *roff implementation,
there is nothing wrong with installing both roff implementations -
and use that macro set, even if distributed with groff, with both.
That works already now, it doesn't require any splitting.
Just like you can use third-party macros with groff, if they are
portable enough to work with groff.

> 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.

I see nothing wrong with supporting Bertrand.  He has already proven
that it is quite easy and pleasant to work with him.

Sure, maintaining macro sets is an easier task than maintaining the
complicated automake / autoconf / C++ beast as a whole.  But i don't
see how splitting out *easier* parts could possibly help with
maintaining the harder parts, and even less so with keeping the
thing as a whole in good coordination.  Having to coordinate with
independent macro releases mike even make the task of the core
maintainer more complex...

Yours,
  Ingo