How about a call for bug-fix volunteers?
Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done). So what if we try to recruit a couple helpers for each library? I see two avenues where we can use some volunteer help to improve boost's quality. 1. Dandelion pickers: look at failed/yellow regression tests and try to fix them. Volunteers could pick a platform they have access to, and try to work across all libraries. You might be surprised at how easy many are to fix. 2. Ticket triage: pick a library and go through all open tickets. Change severity, resolve, request more information, try to map to an existing regression test, interact with the submitter in the comments. (I think Trac needs a "requesting more information" state.) Even a brief 'triage' on each would be helpful, and help users feel they're being heard. (Trac needs to track this, too.) Write new regressions from legitimate issues. Recruiting pitch: it's a great way to improve your skills--troubleshooting, C++, platform-specific expertise, communication. Not so glamorous, but important and great experience. Perhaps we could assign a little of each to each SoC person. Maybe put the word out on Slashdot. See previous topic threads (http://lists.boost.org/Archives/boost/2010/10/index.php) "Report # 29 (aka 1.45 blockers) is too narrow" "[1.45] Beta final schedule" "[1.45] Thread issues"
Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done).
So what if we try to recruit a couple helpers for each library?
I see two avenues where we can use some volunteer help to improve boost's quality.
1. Dandelion pickers: look at failed/yellow regression tests and try to fix them. Volunteers could pick a platform they have access to, and try to work across all libraries. You might be surprised at how easy many are to fix.
Yes please, if anyone would like to investigate the regex or math lib failures on those platforms I don't have access to that would be great! John.
On 10/26/2010 08:00 AM, Jim Bell wrote:
Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done).
So what if we try to recruit a couple helpers for each library?
I see two avenues where we can use some volunteer help to improve boost's quality.
1. Dandelion pickers: look at failed/yellow regression tests and try to fix them. Volunteers could pick a platform they have access to, and try to work across all libraries. You might be surprised at how easy many are to fix. 2. Ticket triage: pick a library and go through all open tickets. Change severity, resolve, request more information, try to map to an existing regression test, interact with the submitter in the comments. (I think Trac needs a "requesting more information" state.) Even a brief 'triage' on each would be helpful, and help users feel they're being heard. (Trac needs to track this, too.) Write new regressions from legitimate issues.
Recruiting pitch: it's a great way to improve your skills--troubleshooting, C++, platform-specific expertise, communication.
Not so glamorous, but important and great experience. Might be fun.
Patrick
On Tue, Oct 26, 2010 at 11:00 AM, Jim Bell <Jim@jc-bell.com> wrote:
Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done).
<snip great ideas> Boost.Apprenticeship? Jim, I think it would be awesome if you would like to run a program like this! Obviously it would take a lot of cooperation from library authors and the rest of the community, but to make something like this work I think it needs a coordinator. What do you say? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
From: boost-bounces@lists.boost.org on behalf of Dave Abrahams Sent: Wed 10/27/2010 9:32 AM To: boost@lists.boost.org Cc: Jim@jc-bell.com Subject: Re: [boost] How about a call for bug-fix volunteers?
On Tue, Oct 26, 2010 at 11:00 AM, Jim Bell <Jim@jc-bell.com> wrote:
Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done).
<snip great ideas>
Boost.Apprenticeship? Jim, I think it would be awesome if you would like to run a program like this! Obviously it would take a lot of cooperation from library authors and the rest of the community, but to make something like this work I think it needs a coordinator. What do you say?
I would definitely sign up for this if it existed. Going from simply using basic templates with C++ to a high grade and quality of single/multithreaded programming can be done by yourself but not always quickly. I have found mentoring to be a way to grab years of wisdom quickly so you don't repeat past mistakes nor rediscover some technique. Stephen
At Wed, 27 Oct 2010 13:15:02 -0400, Torri, Stephen CIV NSWCDD, W15 wrote:
From: boost-bounces@lists.boost.org on behalf of Dave Abrahams Sent: Wed 10/27/2010 9:32 AM To: boost@lists.boost.org Cc: Jim@jc-bell.com Subject: Re: [boost] How about a call for bug-fix volunteers?
On Tue, Oct 26, 2010 at 11:00 AM, Jim Bell <Jim@jc-bell.com> wrote:
Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done).
<snip great ideas>
Boost.Apprenticeship? Jim, I think it would be awesome if you would like to run a program like this! Obviously it would take a lot of cooperation from library authors and the rest of the community, but to make something like this work I think it needs a coordinator. What do you say?
I would definitely sign up for this if it existed. Going from simply using basic templates with C++ to a high grade and quality of single/multithreaded programming can be done by yourself but not always quickly. I have found mentoring to be a way to grab years of wisdom quickly so you don't repeat past mistakes nor rediscover some technique.
You'd sign up to be an apprentice, or to mentor someone? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
From: boost-bounces@lists.boost.org on behalf of David Abrahams Sent: Wed 10/27/2010 2:16 PM To: boost@lists.boost.org Subject: Re: [boost] How about a call for bug-fix volunteers?
Boost.Apprenticeship? Jim, I think it would be awesome if you would like to run a program like this! Obviously it would take a lot of cooperation from library authors and the rest of the community, but to make something like this work I think it needs a coordinator. What do you say?
I would definitely sign up for this if it existed. Going from simply using basic templates with C++ to a high grade and quality of single/multithreaded programming can be done by yourself but not always quickly. I have found mentoring to be a way to grab years of wisdom quickly so you don't repeat past mistakes nor rediscover some technique.
You'd sign up to be an apprentice, or to mentor someone?
Sorry David I should have been more clear that I would sign up as an apprentice. Stephen
On Wed, Oct 27, 2010 at 7:02 PM, Dave Abrahams <dave@boostpro.com> wrote:
On Tue, Oct 26, 2010 at 11:00 AM, Jim Bell <Jim@jc-bell.com> wrote:
Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done).
<snip great ideas>
Boost.Apprenticeship? Jim, I think it would be awesome if you would like to run a program like this! Obviously it would take a lot of cooperation from library authors and the rest of the community, but to make something like this work I think it needs a coordinator. What do you say?
I would love to sign up as an apprentice. I have worked off and on as C++ developer and have used some Boost libraries at work. I have also some experience as a freelance C++ instructor where I have tried my hand at teaching some of the Boost libraries. I have access to the following resources: 1. OpenSuSE 11.2 laptop with gcc 4.3.2 as well as MSVC 2008 on Windows XP. 2. Sandboxes of boost 1.44 and bjam source code and should have no problems upgrading this. 3. About 1 hour daily on weekdays and 4 hours daily on weekends to devote to this. Regards, Arindam
On 1:59 PM, Dave Abrahams wrote:
On Tue, Oct 26, 2010 at 11:00 AM, Jim Bell <Jim@jc-bell.com> wrote:
Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done). <snip great ideas>
Boost.Apprenticeship? Jim, I think it would be awesome if you would like to run a program like this! Obviously it would take a lot of cooperation from library authors and the rest of the community, but to make something like this work I think it needs a coordinator. What do you say?
How about Boost.Quality? I'm honored that you'd consider me, but I've blown past the (time) limit I can spend (with real consequences). Anyone else see where I'm going and want to take this bull by the horns? Or convince your employer to sponsor my involvement? I'm encouraged that we have three volunteers in two days from this mailing list alone. I'd bet we get a bunch more from the User's list if we put a call out on a regular basis. I'd like to hash my thoughts out a bit more. I'll do it on my web-site, but could do it in the boost space if you want.
At Thu, 28 Oct 2010 11:28:11 -0500, Jim Bell wrote:
On 1:59 PM, Dave Abrahams wrote:
On Tue, Oct 26, 2010 at 11:00 AM, Jim Bell <Jim@jc-bell.com> wrote:
Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done). <snip great ideas>
Boost.Apprenticeship? Jim, I think it would be awesome if you would like to run a program like this! Obviously it would take a lot of cooperation from library authors and the rest of the community, but to make something like this work I think it needs a coordinator. What do you say?
How about Boost.Quality?
I'm honored that you'd consider me, but I've blown past the (time) limit I can spend (with real consequences).
Anyone else see where I'm going and want to take this bull by the horns? Or convince your employer to sponsor my involvement?
I'm encouraged that we have three volunteers in two days from this mailing list alone.
Me too!
I'd bet we get a bunch more from the User's list if we put a call out on a regular basis.
I'd like to hash my thoughts out a bit more. I'll do it on my web-site, but could do it in the boost space if you want.
Which boost space? Maybe you'd like to write an article for C++Next? We have pretty high visibility. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Which boost space? Maybe you'd like to write an article for C++Next? We have pretty high visibility.
Which C++Next? Google just pointed me to http://cpp-next.com/ which only gives a "500 - Internal Server Error", Alex.
In message <4CCADD81.7060806@cam.ac.uk>, Alex Hagen-Zanker <ahh34@cam.ac.uk> writes
Which boost space? Maybe you'd like to write an article for C++Next? We have pretty high visibility.
Which C++Next? Google just pointed me to http://cpp-next.com/ which only gives a "500 - Internal Server Error", Alex.
http://cpp-next.com/ works for me. Alec -- Alec Ross
At Fri, 29 Oct 2010 16:10:51 +0100, Alec Ross wrote:
In message <4CCADD81.7060806@cam.ac.uk>, Alex Hagen-Zanker <ahh34@cam.ac.uk> writes
Which boost space? Maybe you'd like to write an article for C++Next? We have pretty high visibility.
Which C++Next? Google just pointed me to http://cpp-next.com/ which only gives a "500 - Internal Server Error", Alex.
http://cpp-next.com/ works for me.
we've had a few availability problems in the last couple of days, but it's working now. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
2010/10/26 Jim Bell <Jim@jc-bell.com>:
Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done).
So what if we try to recruit a couple helpers for each library?
I see two avenues where we can use some volunteer help to improve boost's quality.
1. Dandelion pickers: look at failed/yellow regression tests and try to fix them. Volunteers could pick a platform they have access to, and try to work across all libraries. You might be surprised at how easy many are to fix. 2. Ticket triage: pick a library and go through all open tickets. Change severity, resolve, request more information, try to map to an existing regression test, interact with the submitter in the comments. (I think Trac needs a "requesting more information" state.) Even a brief 'triage' on each would be helpful, and help users feel they're being heard. (Trac needs to track this, too.) Write new regressions from legitimate issues.
Recruiting pitch: it's a great way to improve your skills--troubleshooting, C++, platform-specific expertise, communication.
Not so glamorous, but important and great experience.
Perhaps we could assign a little of each to each SoC person.
Maybe put the word out on Slashdot.
I would like to try help ;-) I should be able to spend up to an hour a day. I have two years of every-day C++ programming experience (with attempts at template metaprogramming etc.). My platforms are 1) Windows MinGW and msys, gcc -v: Target: mingw32 Configured with: ../gcc-4.5.0/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.5.0 (GCC) 2) Linux (gentoo), gcc -v: Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/gcc-4.4.4/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.4 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.4 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.4/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.4/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.4.4/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.4-r2 p1.2, pie-0.4.5' Thread model: posix gcc version 4.4.4 (Gentoo 4.4.4-r2 p1.2, pie-0.4.5) Regards, Kris
On 26/10/10 16:00, Jim Bell wrote:
So what if we try to recruit a couple helpers for each library?
Good idea, but tricky to achieve.
I see two avenues where we can use some volunteer help to improve boost's quality.
1. Dandelion pickers: look at failed/yellow regression tests and try to fix them. Volunteers could pick a platform they have access to, and try to work across all libraries. You might be surprised at how easy many are to fix. 2. Ticket triage: pick a library and go through all open tickets. Change severity, resolve, request more information, try to map to an existing regression test, interact with the submitter in the comments. (I think Trac needs a "requesting more information" state.) Even a brief 'triage' on each would be helpful, and help users feel they're being heard. (Trac needs to track this, too.) Write new regressions from legitimate issues.
Perhaps, it would be feasible and sensible if experienced Boost hackers could provide some sort of review in form of rating, an estimated difficulty (for example, regarding required C++ skills and Boost internals knowledge) for outstanding issues. This could help those less experienced decide which issues to take.
Recruiting pitch: it's a great way to improve your skills--troubleshooting, C++, platform-specific expertise, communication.
Not so glamorous, but important and great experience.
IMO, getting involved in Boost is a great experience, definitely.
Maybe put the word out on Slashdot.
Twitter :-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
于 2010年10月26日 23:00, Jim Bell 写道:
Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done).
So what if we try to recruit a couple helpers for each library?
I see two avenues where we can use some volunteer help to improve boost's quality.
1. Dandelion pickers: look at failed/yellow regression tests and try to fix them. Volunteers could pick a platform they have access to, and try to work across all libraries. You might be surprised at how easy many are to fix. 2. Ticket triage: pick a library and go through all open tickets. Change severity, resolve, request more information, try to map to an existing regression test, interact with the submitter in the comments. (I think Trac needs a "requesting more information" state.) Even a brief 'triage' on each would be helpful, and help users feel they're being heard. (Trac needs to track this, too.) Write new regressions from legitimate issues.
Recruiting pitch: it's a great way to improve your skills--troubleshooting, C++, platform-specific expertise, communication.
Not so glamorous, but important and great experience.
Perhaps we could assign a little of each to each SoC person.
Maybe put the word out on Slashdot.
See previous topic threads (http://lists.boost.org/Archives/boost/2010/10/index.php) "Report # 29 (aka 1.45 blockers) is too narrow" "[1.45] Beta final schedule" "[1.45] Thread issues"
_______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Sounds a good idea. I once fired a ticket 5 month ago about Boost.PropertyTree with a fix patch and unit test against the bug (https://svn.boost.org/trac/boost/ticket/4340), however, it seems no one takes care about it for 5 months. Frustrating me a little bit. And I know how busy everyone is and all is free work here, so please count me in if Boost need more hands, I would love to contribute back to the Boost community. I have 7 years cross platform C++ experience and am accessible to the following tool chains: * Windows 7 x86 VC8.0 * Windows Vista SP1 x86 VC8.0 * Windows 2003 R2 x64 VC8.0 * Ubuntu 10.04 x32 g++ 4.4.3 * Red Hat Enterprise Linux AS release 4 x64 g++ 3.4.4 * SUSE Linux 32bit g++ 4.3.2
On 1:59 PM, ZHUO Qiang wrote:
于 2010年10月26日 23:00, Jim Bell 写道:
Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done).
Sounds a good idea.
I once fired a ticket 5 month ago about Boost.PropertyTree with a fix patch and unit test against the bug (https://svn.boost.org/trac/boost/ticket/4340), however, it seems no one takes care about it for 5 months. Frustrating me a little bit.
I think yours is a good case study for "Ticket Triage." You seem to have done the grunt work to give some very low-hanging fruit for the boost authors to incorporate. But you're not familiar with the ticket system, so you don't mark it 'regression' or don't set the milestone, and it falls through the cracks. (At least I think 'regression' the right setting...) Now I don't know property_tree at all, so getting my mind around your ticket would take more time than I can spend on any random ticket, even a promising-looking one like this. (And this would be the release manager's shoes.) But a volunteer who: * understands property_tree (user-level knowledge, not developer-level), * knew his way around its regression tests (crucial!), * understands Trac & how we're using it... This volunteer could: * interact with the submitter with something he hasn't considered, * mark it 'regression' (or 'feature request') and/or set the milestone * give some other heads-up to the library's author or the release manager that this is a good one to commit back to the trunk. * point the submitter to the closest regression and challenge him to adapt it to show the bug The submitter is heard, the bug gets fixed, boost gets better, and the volunteer sharpens his skills.
On Oct 26, 2010, at 11:00 AM, Jim Bell wrote:
Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done).
So what if we try to recruit a couple helpers for each library?
I also would like to offer my interest in helping out. I am doing C++ for about 13 years now, however, not necessarily to the level of some of you guys around here. Nonetheless, it's always fun to enhance your knowledge and certainly fixing bugs is a good way to get your hands dirty. Since I have seen the other volunteers offering specific timeframes per day/weekend, I would like to understand whether or not these are required as finding time every day may be quite difficult for me given my current job. Certainly the weekends are easier.... Ciao, Andreas
Andreas Masur wrote:
Since I have seen the other volunteers offering specific timeframes per day/weekend, I would like to understand whether or not these are required as finding time every day may be quite difficult for me given my current job. Certainly the weekends are easier....
You can be sure that Boost will welcome any time you are willing to expend in improving the libraries. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (14)
-
Alec Ross -
Alex Hagen-Zanker -
Andreas Masur -
Arindam -
Dave Abrahams -
David Abrahams
-
Jim Bell -
John Maddock -
Krzysztof Czainski -
Mateusz Loskot -
Patrick Horgan -
Stewart, Robert -
Torri, Stephen CIV NSWCDD, W15 -
ZHUO Qiang