Andrey Semashev
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.
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. 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.
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.
Exactly. That's why the maintainer should remain in charge of the overall direction of the library. It's just that there should be a way to overrule them if it's clear to everyone but themselves that they are misguided. In a small project, the community would simply fork it, change its name, and get on with the changes. But with Boost that is plainly impractical. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)