Re: [boost] RFC: Community maintained libraries

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:
> AMDG
> 
> 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.