Boost logo

Boost :

Subject: Re: [boost] RFC: Community maintained libraries
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-12-05 14:58:12

On Thursday 05 December 2013 10:06:55 Steven Watanabe wrote:
> On 12/05/2013 09:36 AM, Alexander Lamaison wrote:
> > ========
> > Proposal
> > ========
> >
> > My proposal goes further than Beman's and gives "Community
> > maintainership" to all but the most well-maintained libraries. Each
> > library would still have a named maintainer and this would be their
> > role:
> >
> > <snip>
> This wouldn't help anything. Every effort to
> create a group that does general maintenance
> in the past has fizzled out when most of the
> participants lose interest. If we can't even
> manage this for a few libraries that have no
> active maintainer at all, it's completely
> hopeless to try to establish it for even more
> libraries.

While I can see why this idea may fail because of lack of interest, I
sympathize Alexander's point that the community should play larger role in
libraries development. There are examples when blanket changes needed to be
applied to multiple libraries, like macro updates Stephen Kelly did. There are
cases when trivial fixes needed to be made in someone else's library. Surely
github adds pull requests to the available options, but pull requests still
have to be processed by a single or a few maintainers, which become a
bottleneck and a single authority about the library.

I think Alexander is making a good point that the membership in the Community
group should represent the right to apply changes and not an obligation to do
active maintenance of every library in Boost. Such an obligation is
unrealistic to fulfill, indeed. But for one, I'd like to be able to make
changes to the libraries I don't develop or maintain.

There is a slippery edge in this idea though. While I'd welcome people making
fixes and relatively small improvements to the libraries I maintain, I'd feel
unease if design decisions were made without my consent. It's not about the
lack of trust for the community, but rather because such decisions could
interfere with my vision of the library utility and future development. Of
course, it is difficult to define which changes are small and which are
considered architectural, and my vision of the library is obviously
subjective. This makes a lot of grey area. Voting doesn't look like a viable
solution, since there may be a simple lack of quorum. Remember that we have
problems with the amount of reviews for libraries, and there's no reason to
believe it'll be different with voting.

I think there has to be an upper hand in controversial and design-defining
cases, and right now I don't see a better candidate than the library
maintainer. After all, he has arguably the best knowledge of the library.

Boost list run by bdawes at, gregod at, cpdaniel at, john at