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.
