Boost logo

Boost :

Subject: Re: [boost] RFC: Community maintained libraries
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2013-12-05 17:09:23

Steven Watanabe <watanabesj_at_[hidden]> writes:

> On 12/05/2013 12:59 PM, Alexander Lamaison wrote:
>> Andrey Semashev <andrey.semashev_at_[hidden]> writes:
>>> 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.
>> I anticipate this only happening in two rare situations, one extremely
>> rare. The more common case would be where a maintainer is uncontactable
>> or unable to devote enough time to make the changes.
> This has never been a real problem in the past for minor
> changes, provided that someone with commit access is
> motivated enough to:
> - Understand the library well enough to avoid
> accidentally breaking something
> - Write the fix
> - Write test cases for the fix
> - Take responsibility for any problems that appear
> - etc.
> The administrative overhead of asking for permission
> on the list is relatively minor. (My usual policy
> is Email 1: Okay to commit? Email 2: It's going in,
> unless someone objects immediately.)

If that's the case, I don't think people realise that's a recognised
route to contribute. When it happens it always seems like an emergency

> For major changes, there will be problems, so if
> the maintainer is missing, then whoever is doing
> the work needs to be willing to step up as the new
> maintainer.

Why? It rules out all but the most dedicated contributors making
significant improvements. Sure, the code needs maintaining, but why
this insistence that that only one person at a time can do that?

>> The second, rare
>> case would be where, after exhaustive debate on the list, the community
>> is overwhelmingly in favour of a direction for the library but the
>> maintainer simply refuses. It's hard to see any reason why the
>> maintainer should be able to veto the whole community for all time.
> I don't see any point in discussing this. I don't
> expect this situation to come up, ever.

Agreed. It's not an important reason for making these changes.


Swish - Easy SFTP for Windows Explorer (

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