Subject: Re: [boost] Community Maintenance Team and neglected libraries
From: Ben Pope (benpope81_at_[hidden])
Date: 2014-04-22 22:46:55
On Wednesday, April 23, 2014 04:08 AM, Edward Diener wrote:
> None of these are in
> the list of libraries which the community maintenance team has write
> acces to apply fixes.
> Hopefully the developers who do have write access to these libraries
> will look at the issues involved.
Not having write access is the problem, it's a barrier to the CMT
achieving their first two goals of keeping boost building and a healthy
It's kind of crazy that if I have a library that other libraries depend
on, and I want to improve that library with a breaking change, there is
no mechanism that allows me to fix that other library. I commit the
change to develop, create pull requests and wait. Nothing happens. Can
I ever commit that change to master? Must I really go through a
several-version deprecation procedure for every change that could
possible break any other library?
If a library author is unresponsive, through what mechanism can we
prevent that library from rotting? Through what mechanism can we
prevent that library from breaking other libraries that depend on it?
Through what mechanism can we prevent that library from holding back the
improvement of other libraries?
The answer must be to grant write access to the CMT for that library for
the purpose of maintenance.
How do we define unresponsive? How big a change should be allowed?
Even if a temporarily unresponsive author reappears on the scene and
dislikes the changes, we have version control. They can undo those
changes and reimplement them themselves. That sounds like a small and
entirely reasonable cost for having been unresponsive. The advantage is
that whilst they were away, their library compiled, the test matrix was
clean, libraries that depend on that library continue to build,
libraries that that library depends on can be changed. The rest of
Boost can continue in the absence of that author.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk