On 5 Dec 2013 at 19:17, Alexander Lamaison wrote:
I've not explained myself well enough. What I'm proposing should not make community reps feel they have to contribute to multiple libraries. Just that they shouldn't be _prevented_ from contributing to libraries, whether that be the one library they have an intereste in, or more than one.
At the moment, no-one but the named maintainer is allowed to commit to a the library, except with case-by-case permission from the release managers when a critical patch is urgently needed in the imminent release.
Even if everyone had commit access to everything, I think you'd find there are powerful social pressures to not fiddle with "other people's code" except in the most minor ways. Even substantial patches are highly likely to be silently ignored by most maintainers, partially due to NIH, partially due to lack of interest in merging and supporting other people's use cases, and partially because in the end it's all about spare time here, and people will naturally choose their todo list over other's. The traditional solution is forking of course, so those interested enough fork a library and take it in new directions. Boost is particularly fork unfriendly however - I don't believe anyone has EVER seriously suggested forking any non-trivial chunk of Boost. I do agree that the steering committee should have admin and commit access to all approved Boost libraries, and possibly all those in the peer review queue as well. To my knowledge this is already planned and/or already implemented, so we're as good as we're at. (FYI I very much like the idea of an active pruning strategy for Boost so undermaintained libraries get actively purged. Less is more!) Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/