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.