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

[John Gardner]

Yikes, that's an ugly dark side.


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


ISC forever!

On 28 April 2017 at 23:09, Ingo Schwarze <address@hidden> wrote:

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