[groff] Macro in separate packages

[Bertrand Garrigues]

(changing the subject)
Hi Dave,

On Wed, Feb 21 2018 at 06:18:40 PM, Dave Kemper <address@hidden> wrote:
> On 2/21/18, Ingo Schwarze <address@hidden> wrote:
>> 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.
>
> Indeed, splitting out easier jobs is a time-honored way to help those
> who have difficult jobs.  Your brain surgeon is probably not also
> answering phones at the hospital's switchboard and managing its
> cleaning crew.
>
> To my view, this *is* a way of supporting Bertrand -- he has
> graciously volunteered to be groff's brain surgeon, and perhaps we can
> make his job easier by offloading work he's already said he doesn't
> feel as comfortable doing.

I'm not comfortable in making non-trivial changes in existing macro
packages.  However as I leave this work to other persons in the list
this does not give my any extra work.  For any build issues related to
macro package build or installation it's autoconf/automake so it's part
of my job.

> Sometimes it's better to take the "easy" stuff off the plate of those
> who have to deal with the difficult parts, so they can better focus
> their attention.

Splitting groff into 2 packages would not make my task easier, it would
probably make it more complex.  When I build groff I check the examples
from 'mom' and examples from other macro packages as a sanity check: if,
says, the 'mom' examples are broken I can start to look for some
problems on my system (fonts, ghostscript version etc...) or for some
regressions in the git history.  If the macro set were in a separate
package it would be an extra source of dependencies and problems.

My thoughts on this topic:

I don't know how easy it is to use macro package from groff on another
*roff implementation.  As Ingo said the groff full installation can live
on a system with another *roff installation, this works (the build
system detects if an existing 'troff' is already installed and add a 'g'
prefix to 'troff').  If for some reason the user does not want to
install the full 'groff' installation then we could define new make
targets, for example 'make macro' and 'make install-macro' to build and
install only the macro packages.

Would this help?

The other thing is that you probably want to have official release of
macro packages independantly from releases of the core system.  If there
is real need for that then we could make some stable branches and
intermediate releases, following this flow:

- Full version is released, e.g. 1.22.4.

- A little bit later a macro package maintainer wants to make a release
  that has no dependencies on the core system, but there were some
  non-trivial changes since 1.22.4 and we are not ready to make a full
  1.22.5 release.  In order to avoid regressions we make a stable branch
  from tag v1.22.4 and the macro package maintainer commits on it, and
  creates a 1.22.4-1 release.

This is only a matter of a few git commands and is easy to do (compared
to having to manage 2 distinct packages).  The macro package maintainer
could also request the proper rights from GNU to push releases, this
does not even require an official maintainer status, I could declare him
as a person of trust allowed to make release (there would be some
administrative stuff to do though).

Regards,

Bertrand Garrigues