Subject: Re: [boost] Your Boost Needs You!
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-12-31 10:07:54
I'm just on vacation, but soon as I get back to the home office (tomorrow,
PHT) I'll be battle ready to help out on Boost.Pool. Thanks John, I look
forward to getting more details on what else needs to happen.
Sent from my Mobile Device
On Dec 30, 2010 8:10 PM, "John Maddock" <boost.regex_at_[hidden]> wrote:
There's been a lot of discussion lately about improving participation in
Boost, this is a call to arms for a *small* initial experiment which I hope
will grow into something bigger, perhaps after some tweaking to the initial
experiment. The aim is to merge the ideas put forward for a Boost Guild,
with mine for a roving hit squad to tackle neglected libraries. It goes
* Someone, lets call him a manager/mentor/maintainer puts forward a library
that has a large number of open tickets against it and which maybe hasn't
seen maintenance in some time.
* The manager creates a copy of that library in the sandbox for folks to
* The volunteers either submit patches or - preferably - commit patches
direct to the sandbox copy. Work continues for a month or two until
everyone agrees that they have a release ready update (tested locally by the
* The manager reviews the changes and either: merges the changes to Trunk,
or files a clear list of things to do to make the update acceptable.
* If the Trunk tests don't pass (and the fix isn't obvious/trivial) the
manager throws the problem back to the volunteers, otherwise merges to
The aim is to:
* Minimize the "manager/maintainer/mentor" bottleneck by having one review
of a whole set of changes to one library, rather than having to deal with
lots of little patches from all the over the place.
* Maximize the chances that the volunteers achieve something meaningful in a
defined set of time, by defining clear goals from the outset, and selecting
a manageable target from the many folks could choose - currently we suffer
from the "too much to choose from or do, so why do anything" dilemma.
* The manager undertakes the responsibility for stewarding the update
through to the release branch - frankly this is only possible by the mentor
dealing with one library at a time, otherwise the "many small patches"
problem quickly becomes overwhelming.
* Give recognition to volunteers for their efforts, first by providing the
"I did that" feeling from working towards a specific target, second by
adding acknowledgements or in the case of partial (or complete!) rewrites,
co-authorship to the docs.
Like I said the aim is to start small with an experiment (low risk, low
expectations) to see how it goes... then refine the process... and hope we
can grow it into something larger over time.
For this I'm prepared to act as the mentor/manager for an update to the pool
library (though I'm certainly open to other suggestions, and if someone else
would like to take on the manager/mentor role then by all means fell free!
:-) ). I chose this library because it's seen essentially no maintenance
(and certainly no maintainer) since it was written, and because on the face
of it, it looks to be a manageable task for folks to take on.
So... let me know if you're interested, and if there's enough people I'll
define the goals and get things started,
Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk