Boost logo

Boost :

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


Currently unemployed and looking for work in Ireland.
Work Portfolio:

Boost list run by bdawes at, gregod at, cpdaniel at, john at