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 like this: * 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 work on. * 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 volunteers). * 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 Release. 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, Regards, John.
On 30/12/10 13:07, John Maddock wrote:
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. I like the idea and i like the choice of pool to be updated. It is a small yet very valuable piece of software, I'll be glad to see it updated/upgraded :)
On 12/30/2010 04:31 AM, Joel Falcou wrote:
On 30/12/10 13:07, John Maddock wrote:
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. I like the idea and i like the choice of pool to be updated. It is a small yet very valuable piece of software, I'll be glad to see it updated/upgraded :)
Agreed! Great idea and the library is one that Joel and I have discussed updates/upgrades to for some time. Thank you John for picking up the mantle. Count me in! -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On Dec 30, 2010, at 4:07 AM, John Maddock wrote:
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,
Great idea, and great choice! -- Marshall
On Dec 30, 2010, at 4:07 AM, John Maddock wrote:
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.
I created a custom report in Trac: Open Tickets for Boost.Pool: https://svn.boost.org/trac/boost/report/32 -- Marshall
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Thursday, December 30, 2010 12:08 PM To: boost@lists.boost.org Subject: [boost] Your Boost Needs You!
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 like this:
* 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 work on. * 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 volunteers). * 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 Release.
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,
This seems an excellent structure (provided we can get enough - preferably competent! - 'managers'). I've not been willing to volunteer because of the risk of messing-up - perhaps big-time, and very publicly! But this seems to reduce the risk to acceptable levels. (And perhaps we can take the opportunity to improve documentation while we are at it). Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
OK it's looks like we have a few volunteers for Boost.Pool (but always room for a few more!), to kick things off, there is now a copy of Pool in the sandbox under guild/pool. Just check out sandbox/guild (no need for the whole sandbox unless you want it) and all the Jamfiles in that tree should work OK if you set the environment variable BOOST to point to your main Boost tree. There is also a temporary mailing list for Pool related discussion here: http://groups.google.com/group/boostpool and an initial TODO list here: http://groups.google.com/group/boostpool/web/boost-pool-tasks Also if anyone has any pending issues or requests for Pool, now is the time to file them on the Trac! Regards, John.
On 30/12/2010 12:07, John Maddock wrote:
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,
I'm willing to give it a try as a volunteer. :) KTC
On 12/30/2010 7:07 AM, John Maddock 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 like this:
* 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 work on.
Why not just branch the library in the main Boost area and then give access to anybody you want to work on it to there ? Is not that what branches in SVN is all about. Copying to the sandbox seems unnecessary.
On 12/30/2010 02:02 PM, Edward Diener wrote:
On 12/30/2010 7:07 AM, John Maddock 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 like this:
* 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 work on.
Why not just branch the library in the main Boost area and then give access to anybody you want to work on it to there ? Is not that what branches in SVN is all about. Copying to the sandbox seems unnecessary.
The sandbox is in svn now and a copy in svn is the same as a branch. -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On 12/30/2010 5:19 PM, Michael Caisse wrote:
On 12/30/2010 02:02 PM, Edward Diener wrote:
On 12/30/2010 7:07 AM, John Maddock 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 like this:
* 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 work on.
Why not just branch the library in the main Boost area and then give access to anybody you want to work on it to there ? Is not that what branches in SVN is all about. Copying to the sandbox seems unnecessary.
The sandbox is in svn now and a copy in svn is the same as a branch.
According to the docs, a branch initially makes a link in the repository pointing to a specific tree/revision and does not do a full copy.
AMDG On 12/30/2010 3:43 PM, Edward Diener wrote:
According to the docs, a branch initially makes a link in the repository pointing to a specific tree/revision and does not do a full copy.
That's what svn cp does. There is no difference between a branch and any other copy. In Christ, Steven Watanabe
According to the docs, a branch initially makes a link in the repository pointing to a specific tree/revision and does not do a full copy.
An SVN copy is how you create a branch - in fact there are no branches as such in SVN - just "cheap copies" when you move from part of the repository to another (Trunk and Sandbox are part of the same SVN tree but have different commit permissions). John.
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@virgin.net> 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 like this: * 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 work on. * 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 volunteers). * 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 Release. 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, Regards, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (9)
-
Dean Michael Berris -
Edward Diener -
Joel Falcou -
John Maddock -
KTC -
Marshall Clow -
Michael Caisse -
Paul A. Bristow -
Steven Watanabe