Beman Dawes
Boost libraries have always been maintained by an individual maintainer, or perhaps a small number of individuals. That works very well most of the time, and there is no need to change that approach for libraries that continue to have active maintainers.
Where we have a problem is libraries that don't have active maintainers. Someone else has to step in from time-to-time to apply patches and perform other routine maintenance. That was easy to do for our svn repo because write permissions were global.
... snip This is something I've been thinking about recently, since all the hoohaa when Stephen Kelly tried to clean up multiple libraries: ===================================== The role of Boost library maintainers ===================================== Boost's approach is unusual for an open-source project in that it considered a maintainer to be a library's single point of contribution rather than a guide and mentor for multiple contributors. Even open-source projects with a clear BDFL do not expect every patch to pass through that that single person. Instead there are a select group of committers who are trusted to make sensible decisions. On occasion, the BDFL may object to a change that has been committed and argue for it to be rolled back, but there is no 'prior restraint' of the type practised by Boost. So why is this a problem? The cost of this approach is clear from this list alone. Patch submissions are ignored. Bug reports are not dealt with. Discussions about improvements come to nothing because the one person able to do anything about them, the maintainer, loses interest. None of this is the maintainer's fault. They are all busy people and naturally more motivated by their own use-cases than by those of others. However, this is also the reason why giving one person absolute control over each library is not in the project's best interests. Sure, in theory a library can be passed to a new maintainer if the previous one is considered to be absent, but this is very rare partly because of how we define a maintainer's status. ================= Maintainer status ================= The discussions on here treat this as a binary: a maintainer is active or absent. The trouble is, it doesn't work like that. Even active maintainers have very different levels of engagement. A maintainer who commits the occasional a bug fix is considered active, and yet their library is never going to be exploring new territory or pushing boundaries the way an enthusiastically maintained one is. Maintainers who have just enough involvement to act as a 'keepalive' are considered active and the library is left in their sole control. ======== 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: Rights of the library maintainer -------------------------------- - To make any changes to the library they see fit, unless overruled by a formal vote (see below). - To roll back any changes made to the library by others, unless overruled by a formal vote (see below). Responsibilities of the library maintainer ------------------------------------------ - To respond to bug reports for their library in a timely manner. - To incorporate or reject patches contributed by others in a timely manner. - To evolve the library to keep up with changes to the C++ language or emerging best-practice (e.g. current example: supporting move semantics). Then the 'community representatives team' have the following additional rights and responsibilities: Rights of the community representatives ---------------------------------------- - To make _any_ changes to _any_ library. - To override the wishes of the library maintainer where there is a formal vote in favour of such action. Responsibilities of the community representatives ------------------------------------------------- - To apply patches contributed by the wider community in a timely manner once there is consensus that it should be applied. ========= Rationale ========= There is general agreement that the library acceptance review process, which puts community consensus above all else, has been key to Boosts quality and success. And yet, once that review is over, complete control is handed from the community to the maintainer, never to return. This proposal aims for a better balance where the work can be spread between more people, where the community can force progress if necessary, and which doesn't ignore the importance of a having a single 'champion' to guide the library's course of ordinary development. The intent is that the following activities are part of everyday Boost development: - Community reps fixing bugs in library they don't maintain, without asking permission from the maintainer. - Community reps applying patches contributes by community, without asking permission from the maintainer. - Maintainers fixing bugs. - Maintainers making significant changes to their own library. And the following activities should be possible by rare: - Maintainers rolling-back changes made by community reps and explaining the decision on this list. - Community reps making significant changes to a library that were requested by the community but whose maintainer was unwilling/unable to implement them. The key to this change is trust. Firstly trust in the community to make reasonable decisions by consensus (we already trust it to do this for acceptance reviews). Secondly, trust in the selected band of 'community representatives' to make sensible changes to the code - this trust has so far been missing from Boost. Comments welcome. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)