Re: [boost] Transfer of Maintenance Rights

Subject: Re: [boost] Transfer of Maintenance Rights
From: Edward Diener (eldiener_at_[hidden])
Date: 2010-03-27 10:52:48

On 3/27/2010 3:38 AM, Vladimir Prus wrote:
> Christian Holmquist wrote:
>> On 26 March 2010 10:05, Rutger ter Borg <rutger_at_[hidden]> 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.