Re: [boost] Community Maintenance Team and neglected libraries

Subject: Re: [boost] Community Maintenance Team and neglected libraries
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-04-30 07:07:51

On 30 Apr 2014 at 5:13, Rob Stewart wrote:

> >> If a maintainer is unresponsive for an extended period, despite
> >contact attempts through the list, private e-mail, and any other means
> >at the community's disposal, then we can declare the library orphaned
> >and assign a new maintainer. Until that time, you're stuck.
> >
> >So for a one line fix to the failing test(s) we should have to jump all
> >the way to orphaned status and find somebody willing to maintain the 
> >entire library for the foreseeable future?  Is that a process that
> >seems workable to you?
> 
> Honoring the maintainer's ownership is appropriate. We expect more
> responsiveness than you imply. When that isn't the case, it indicates
> bigger problems. 

It should also be mentioned that being maintainer for a Boost library 
is a thankless, time consuming, financially unsustainable role with 
very little reward and an awful lot of grief. The fact anyone does it 
- let alone volunteers to do it - is surprising.

Historically, one of the things granted to those willing to invest 
the considerable resources in acting as a maintainer is total and 
absolute control and discretion in all matters relating to 
maintaining that library. I think that is one of the few good reasons 
people volunteer to maintain - they get to enact their personal 
vision for a library. And that definitely means giving pause to 
"simple" bug fixes.

As a quick example of why pondering and delaying applying bug fixes 
is important, I recently ripped out over 120 lines recently added to 
a major Boost library to fix a bug no one ever had a real problem 
with but which broke compilation on a major toolset. I replaced that 
code with 15 lines fixing the non-bug and restoring the ability to 
compile. The original patch was well intentioned and competently 
written, but was written more as C than C++ and spammed many source 
files with #ifdef's when a type with a call operator let the compiler 
switch implementation for you.

It's small stuff like that which is important. I should add, if 
anyone has a problem with the slow pace of bug fixes being applied in 
Boost, they can feel absolutely free to volunteer to help a 
maintainer in general maintainance of a library. I am very sure that 
few maintainers will turn down high quality help. If you really need 
some bug fixed, try fixing ten bugs earlier in the submission queue, 
and I think you'll find that your bug will usually get seen to 
quicker.

Niall

-- 
Currently unemployed and looking for work in Ireland.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/