Re: [boost] RFC: Community maintained libraries

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

Beman Dawes <bdawes_at_[hidden]> writes:

> 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)