On Wed, Dec 4, 2013 at 7:47 AM, 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.
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++ Librarieshttps://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