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

[Dave Kemper]

Thanks, Ingo.  You make some good points.  A few responses inlined below.


On 2/21/18, Ingo Schwarze <address@hidden> wrote:
> 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.

Yes, but this truism scales upwards.  For instance, X Windows pretty
much requires a window manager on top of it -- you probably *could*
run it without one, or write your own, but these cases are exceedingly
rare.  That doesn't mean that X and your chosen window manager have to
be in the same package -- indeed, it's much better that they aren't.
Each package focuses on a single, specific piece of the overall
puzzle.

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

Yes, it's unclear where packages that were written specifically with
groff extensions -- I know -mom also falls into this camp -- would
live under this proposal.  I was thinking more in terms of the
classical macro packages that long predate groff and are fairly
portable across *roff implementations.

-mom is sort of already its own beast, as it has a version numbering
system independent of groff's.

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

This issue is hardly exclusive to groff.  Plenty of FLOSS packages
have dependencies on specific versions of other packages, and the
system's package manager must be aware of which versions of package A
are required by package B, often with complex dependency trees.  Even
with two packages, the groff part of that tree would be trivial.

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

I apologize if anything I said could be construed as against Bertrand
in any way.  I was responding (to a post he made some months ago) to
his statement that he was comfortable with the groff code base but not
the macro packages.  I think a number of people have the opposite
skill set.  It's fine for all these people to come together under one
umbrella and contribute what they can, and that system has worked for
decades.  I'm just brainstorming alternate approaches.  Honestly, I'm
not even advocating *for* such a split right now, just exploring the
idea.

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

> Having to coordinate with
> independent macro releases mike even make the task of the core
> maintainer more complex...

It might, though it seems to me that all the dependencies should go
the other direction: macro packages may require specific features in
groff, but I'm not sure how the reverse could be true.  There may be
edge cases I'm unaware of, though.