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

[Ingo Schwarze]

Hi Dave,

Dave Kemper wrote on Wed, Feb 21, 2018 at 06:18:40PM -0500:
> On 2/21/18, Ingo Schwarze <address@hidden> wrote:

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

The example doesn't really apply: There are dozens of different
window managers, some of them of similar size as X itself and with
larger teams than X itself (GNOME, KDE, ...) - of course it wouldn't
make sense to include all those - or even any of those large ones -
into X.  But groff only has a handful of macro package, all of them
are very small, even if only compared to the rest of groff which
isn't large either, and the total number of active developers on
all macro packages combined is - about two or so?

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

As a matter of fact, the Xenocara distribution (X11 in OpenBSD)
does include two window managers, one of them tiling:  fvwm1 and cwm.
Both of them are tiny compared to the rest of X, and it is very
convenient that they allow using X out of the box without installing
any other package.  In fact, i am using fvwm1 and i'm happy with
it, and with the fact that i don't need another package.  Of course,
poeple are still free to install huge additional packages in addition
if they want them, like XFCE or GNOME or KDE, but it is really nice
that it is not required.

For groff, the situation is even clearer:  It costs almost nothing
to include the full set of all free macro packages that have been in
wide use during the last three decades.  If there is an active
maintainer for a given package, it causes no friction for that
person to provide independent, intermediate releases of that macro
set alone, like Peter consistently shows with mom.

Sure, there are proven ways to deal with dependency chains, but
those are simply not needed here, the task at hand is much simpler.

[ snip ]

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

Like the core groff manual pages only building with groff (including
the groff man macros) and with no other roff interpreter, to name
just one obvious example?  Oops, now we have a cyclic dependency
right there.  Bummer.

If there is no real need to manage dependencies, your life is simpler
if you just don't do it.  My point is to keep things simple when
complexity can easily be avoided.

Yours,
  Ingo