Boost logo

Boost :

Subject: Re: [boost] RFC: Community maintained libraries
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-12-05 17:49:16


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/



Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk