Re: [Groff] bug in macro '.IR' (was ASCII Minus Sign in man Pages).

[Ingo Schwarze]

Hi,

Werner LEMBERG wrote on Fri, Apr 28, 2017 at 07:54:55AM +0200:
> g.branden.robinson wrote: 

>> It'd be nice if 3 year-old bugs could get some feedback from the
>> maintenance team.
>> 
>> What needs to happen to make that possible?

> A new maintainer.

While that would no doubt be excellent, a few additional people who
regularly propose bugfix patches and who regularly review and commit
existing bugfix patches would already mitigate the worst problems,
even if those people do not take the hat of "maintainer" right away.

Carsten Kunze has demonstrated recently that providing relevant help
of exactly that kind is feasible and very worthwhile, even without
becoming "the maintainer".

Bertrand Garrigues has even volunteered to coordinate a release,
and even though that project isn't finished yet, given the excellent
experience with his work on automake integration, i trust that he
will eventually complete it.  Unless i missed something, he did
not say that he intends to become "the maintainer", either.

Yours,
  Ingo


P.S.
Past experience has demonstrated that willingness to take
maintainership alone is insuffient to help the project if it
is not accompagnied by actively doing some real work on the
project.

In practice, people who actively both contribute patches and review
and commit patches sent in by others are most likely to eventually
become fit for and agree to take maintainer responsibility -
without having to commit to full responsibility early on.

Admittedly, in a core GNU project, this normal process of acquiring
new developers is harder than in other projects because new committers
are required to sign the FSF Copyright Assignment (a legal contract
under the law of the State of Massachusetts).  That contract does
not only attempt to transfer ownership of Copyright, but also
contains additional clauses requiring the developer to provide some
specific warranties to the FSF and hold the FSF harmless from damage
arising out of breach of that warranty.  While it may not seem
likely that a well-meaning, diligent developer suffers financial
loss due to unintentional breach of those clauses, some developers
(myself included) are unwilling to sign such provisions (both
regarding transfer of Copyright and regarding warranties) and hence
cannot become committers.

Those artificial barriers make it even more important that those
people who do not mind signing an FSF Copyright assignment do
actively contribute, and if that should result in an invitation to
join the groff project, become committers and help to review and
commit (or reject if need be) those patches that would otherwise
be stuck in the bugtracker.