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

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

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

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

[Dave Kemper]

Catching up with some old groff-list email:


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

Re: [Groff] Next release - maintainership

[Peter Schaffter]

On Wed, Nov 08, 2017, Gour wrote:
> On Wed, 27 Sep 2017 19:02:48 -0400
> Peter Schaffter  wrote:
> 
> Hello Peter,
> 
> I have visited your site and I'm thrilled with the beauty of your documents
> produced with groff/mom and must admit that mom is the primary reason I'm
> looking whether groff/mom can eliminate my need to depend on LyX/LaTeX or
> pursue path of ConTeXt...it seems groff does better job for paper than 
> texinfo,
> although not sure (yet) about Unicode/UTF-8 support...
> 
> > I would like to have put myself forward, but stretched retinas in
> > both eyes means I have to reduce the time I spend staring at the
> > monitor significantly.  So I'm both pleased about your decision and
> > somewhat relieved.
> 
> Does it and how much influences the state and further progress of mom package?

I'm still maintaining the mom package, fielding bug reports and
implementing feature requests.

-- 
Peter Schaffter
http://www.schaffter.ca

Re: [Groff] Next release - maintainership

[Gour]

On Wed, 27 Sep 2017 19:02:48 -0400
Peter Schaffter  wrote:

Hello Peter,

I have visited your site and I'm thrilled with the beauty of your documents
produced with groff/mom and must admit that mom is the primary reason I'm
looking whether groff/mom can eliminate my need to depend on LyX/LaTeX or
pursue path of ConTeXt...it seems groff does better job for paper than texinfo,
although not sure (yet) about Unicode/UTF-8 support...

> I would like to have put myself forward, but stretched retinas in
> both eyes means I have to reduce the time I spend staring at the
> monitor significantly.  So I'm both pleased about your decision and
> somewhat relieved.

Does it and how much influences the state and further progress of mom package?


Sincerely,
Gour

-- 
Everyone is forced to act helplessly according to the qualities
he has acquired from the modes of material nature; therefore no
one can refrain from doing something, not even for a moment.

Re: [Groff] Next release - maintainership

[Peter Schaffter]

Bertrand --

On Wed, Sep 27, 2017, Bertrand Garrigues wrote:
> OK then I volunteer to be a maintainer.  As said previously I won't be
> able to address all the problems submitted on the list, but I can still
> take in charge part of the work.

I, for one, welcome your taking on the role of maintainer.
Reviewing your group posts and commits over the last couple of years
amply demonstrates your suitability and your commitment to groff.

I would like to have put myself forward, but stretched retinas in
both eyes means I have to reduce the time I spend staring at the
monitor significantly.  So I'm both pleased about your decision and
somewhat relieved.

Following Werner, you're stepping into a big pair of shoes.
May the Force be with you. :)

-- 
Peter Schaffter
http://www.schaffter.ca

Re: [Groff] Next release - maintainership

[Bertrand Garrigues]

Hi Ted,

On Sat, Sep 16 2017 at 08:43:05 PM, Ted Harding  
wrote:
> So my suggestion would be that someone who knows their way
> around the organisation of gnu.oeg (and I find it confusing!)
> should undertake the task of establishing a real maintainer.
> This might require someone to explicitly volunteer.

OK then I volunteer to be a maintainer.  As said previously I won't be
able to address all the problems submitted on the list, but I can still
take in charge part of the work.


> Sorry to be unhelpful -- but I hope the above may be useful.
> I'm willing to try to do what I can to help this along.

I've discussed that with Werner: as he no longer has a maintainer status
but you still do, he thinks you should mail to maintain...@gnu.org to
clarify your current status and add me as a new maintainer.

Thanks,

Regards,

Bertrand Garrigues

Re: [Groff] Next release - maintainership

[Ted Harding]

[See in-line below]

On Sat, 2017-09-16 at 21:11 +0200, Bertrand Garrigues wrote:
> Hi all,
> 
> I'm currently preparing the next release of groff (I still have to
> commit a few changes in the build system but I'm not far from making a
> candidate package).  In order to upload a tarball (into alpha.gnu.org
> and ftp.gnu.org) I mailed ftp-upl...@gnu.org so that they could give me
> access to these ftp site, but apparently not being the official
> maintainer is a problem, here is was they answered:
> 
> "The currently listed maintainer for groff is Ted Harding
> . Only him or an uploader nominated by him
> can have their key added to the ftp server. If he has stepped down as
> a maintainer this needs to be resolved prior to requesting a new
> uploader key to be added. Please discuss this within the project and
> request any changes in the maintainers to maintain...@gnu.org. When
> the new maintainer(s) are added to the files then they can request
> their key to be added to the ftp, alternatively they can nominate
> uploaders to have their keys added too."

My "maintainer" role (insofar as I possibly officially had one)
has always been marginal, especially compared with Werber's.
I think that the above reply may be either mistaken or out-of-date.
Visiting the groff web=page at gnu.org
  https://www.gnu.org/software/groff
shows:
[A]: User issues lead: Ted Harding.
[B]: Technical issues lead: Werner Lemberg.
but does not state that either of us is a maintainer (in the GNU
sense of the word).

Further, the following paragraph is in the panel at top right:

  GNU troff is looking for a maintainer. If you’re interested,
  please take a look at this general information about GNU
  packages and being a GNU maintainer, and then email
  maintain...@gnu.org with a bit about your background
  and particular interest in this package. Thanks. 

I don't know who wrote this (maybe Werner), but it indicates
that, in fact, groff lacks a maintainer! And I wonder where
(I couldn't track it down on the above web-page) the groff
maintainer[s] are/is listed.

So my suggestion would be that someone who knows their way
around the organisation of gnu.oeg (and I find it confusing!)
should undertake the task of establishing a real maintainer.
This might require someone to explicitly volunteer.

Sorry to be unhelpful -- but I hope the above may be useful.
I'm willing to try to do what I can to help this along.

Best wishes to all,
Ted.


> 
> 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".
> 
> So what should we do now?
> 
> Regards,
> 
> Bertrand Garrigues
> 

[Groff] Next release - maintainership

[Bertrand Garrigues]

Hi all,

I'm currently preparing the next release of groff (I still have to
commit a few changes in the build system but I'm not far from making a
candidate package).  In order to upload a tarball (into alpha.gnu.org
and ftp.gnu.org) I mailed ftp-upl...@gnu.org so that they could give me
access to these ftp site, but apparently not being the official
maintainer is a problem, here is was they answered:

"The currently listed maintainer for groff is Ted Harding
. Only him or an uploader nominated by him
can have their key added to the ftp server. If he has stepped down as
a maintainer this needs to be resolved prior to requesting a new
uploader key to be added. Please discuss this within the project and
request any changes in the maintainers to maintain...@gnu.org. When
the new maintainer(s) are added to the files then they can request
their key to be added to the ftp, alternatively they can nominate
uploaders to have their keys added too."

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

So what should we do now?

Regards,

Bertrand Garrigues