Re: [boost] RFC: Community maintained libraries

Subject: Re: [boost] RFC: Community maintained libraries
From: Cox, Michael (mhcox_at_[hidden])
Date: 2013-12-05 17:21:15

On Wed, Dec 4, 2013 at 7:47 AM, Beman Dawes <bdawes_at_[hidden]> wrote:

> 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.
>
> GitHub gives us some additional tools; write permissions are given at the
> Team level, and a team can have permissions across multiple specific
> repositories.
>
> Strawman Proposal
> -------------------------
>
> For Boost libraries where there is no library maintainer available, turn
> maintenance over to a "Community" team. Initially the team members would be
> volunteers who are already known as experienced maintainers or patch
> submitters. New volunteers for team membership would establish themselves
> by submitting patches and pull requests. At least to get things started,
> the release managers could OK requests for team membership.
>
> We might seed the list of libraries being community maintained by
> contacting some current maintainers who have not been active for years. If
> we can't even contact the maintainer, that's an indication the library is a
> candidate for community maintenance. Patch submitters who haven't gotten
> any action can request a library be added to community maintenance. At
> least to get things started, the release managers could OK requests for
> community maintenance.
>
> Comments?
>
Now, a comment from the dark-side of software development...

Caveat:  I'm new to the Boost development culture and open source
development, in general, so take the below with a grain of salt.  I'm
playing a little devil's advocate, here, since no one mentioned this
alternative...

Every development team has limited resources and has to triage their work.
 In this case, I'm talking triage in the most severe sense: not just what
order to do something, but if it should be done at all.  Some libraries may
have to be dropped from Boost due to lack of user interest or unlikeliness
of ever being accepted into the C++ standard.  Dead wood has to be cut from
the tree so the rest of the tree can thrive.

In the open source world is very market-driven. The strong (useful/popular)
survive, the weak (limited usefulness/popularity) perish.  For example, in
GCC if a machine architecture loses it's maintainer, the architecture is
deprecated and then dropped in a future release. What's Boost's deprecation
policies?  Doing a search for "library deprecation deprecate" of the
boost.org web-site, the only thing I could find was

Guidelines/MaintenanceGuidelines – Boost C++
Libraries<https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines>

which really doesn't have the tone of a policy or address deprecation of
entire libraries.  Also, the search revealed only one library (Compose)
that has been deprecated.  Is this the only one?  Maybe it's time Boost
needs to get into a pruning mode and remove any deadwood?

Some comments and open questions in regards to the membership of the
Community team concept for a maintainer-less library (MLL) and how it
operates:

   - Users of an MLL can be categorized into two groups:  external users
   and Boost library maintainers whose library is dependent on that MLL.  Yes,
   whether you like it or not, all library maintainers of a library that is
   dependent on an MLL is, in reality, a member of the Community team for that
   library.
   - Maybe there needs to be multiple Community teams, one for each MLL?
   The size of an MLL's Community team will be a good indicator of the
   library's usefulness.  At least it would provide a candidate list for
   possible library maintainers.
   - With the above understanding, the library maintainers have a choice of
   maintaining the dependent MLL or removing their dependence on that MLL.
    With this choice, either the dependent MLL will be maintained by the group
   of users of the MLL or the library will become irrelevant.  If a MLL is not
   being used, it should be removed from Boost.
   - In modularized boost, removing a library that is no longer being used
   is as easy as removing it from the .gitmodules file and prepending a
   note to the README.md file stating such. The MLL's repository can remain in
   boostorg and added back if a maintainer can be found.  This puts pressure
   on the external users to maintain the libraries they use.
   - If a majority of the Community team members feel the maintenance of
   the MLL is too burdensome, the library can be deprecated and will be
   removed in the next release.  Variations of this could be to
      - Limit this decision to just the boost library maintainers (since
      they will probably bear most of the burden).
      - Something more or less than a majority of the Community team.
      - More than a one release deprecation period (or don't commit to a
      specific release so that any future release could be a candidate for
      removal).
      - The value of a Community team member's vote should be proportional
      to the amount of work they've contributed to the maintenance of the MLL.
       Yes, I know this is hard to quantify.

Michael

> --Beman
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost