On Dec 5, 2013, at 5:49 PM, "Niall Douglas"
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.
Perhaps the issue is that those relatively new to Boost don't understand what happens, over the years, that seems normal to longtime members of the community. Documentation would solve that.
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.
This is one such misunderstanding. Others can, and do, make changes. However, they seek permission from the maintainer as a courtesy.
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.
That's always the case and it serves to squelch overreaching change.
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 superlative, "highly," mischaracterizes the attitude of most Boost maintainers.
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.
Signals2 is an excellent example of just such a thing. We also have cases like Lambda vs. Phoenix. ___ Rob (Sent from my portable computation engine)