On 3/27/2010 3:38 AM, Vladimir Prus wrote:
Christian Holmquist wrote:
On 26 March 2010 10:05, Rutger ter Borg <rutger@terborg.net> wrote:
Christian Holmquist wrote:
Which libraries are in the state of no maintainer and how serious are their bug lists at this moment? I guess there's a difference between "no maintainer" and "unmaintained"/"needs more attention".
Cheers,
Rutger
Nit pickings aside, what is the immediate problem? This whole thread seems very theoretical to me. A lot of energy put into it from many people, that maybe could be used to improve the current state of affairs instead (i.e. by fixing bugs in abandoned libs)?
I think the immediate problem is this report of number of open tickets per component:
https://svn.boost.org/trac/boost/report/19
Some of those issues are surely bugs that happen only on VAX machines, or misuses of library, or features only submitter wants, but when a library has 70, or 50, or 40 it still sounds too much.
There does seem, from this end-user's perspective, some libraries where the original developer does not seem to be working on it anymore, whether to fix bugs, update docs, or possibly to make changes. This is quite understandable if a library does not need changes aside from the very occasional bug, which is probably the case with many libraries. I will cite a few where it seems to me that the original developer is nowhere around anymore, but this is just subjective and I might be totally wrong: iostreams date_time tokenizer random value_init variant pool format array Again let me reiterate that I am neither trying to create work for Boost developers nor in any way trying to put down anyone. My earlier post about maintenance of Boost libraries, which Robert Stewart happily turned into specifics, was just an attempt to suggest that when a Boost library has no one maintaining it anymore it would probably be easier to try to find someone else to maintain it than rely in a series of individuals trying to understand it and make changes to it. I wrote that because from my perspective it takes much effort to really understand library code for a Boost library, and it is better to have one ( or possibly a few ) maintainers of a library who invest the time to understand it thoroughly rather than a number of people who may understand only small parts and attempt to fix problems or make changes.