[Bug Sprint] Final report for the (late 2010) Bug Sprint
Well, the bug sprint is over. [ But that doesn't mean you have to stop fixing bugs if you don't want to! ] There were 25 changes to the trac database yesterday - not counting all the spam. [ I'd like to say "25 tickets were changed", but some tickets were changed more than once. ] In this sprint, we looked at (and modified) a couple hundred tickets, resulting in a net drop of 16 tickets from the start of the Bug Sprint. General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow Overall bug count: November 26: 946 November 27: 939 November 28: 930 November 29: 934 (whoops, that's the wrong direction!) November 30: 931 (better, but the delta is too small) December 1: 929 December 2: 930 December 3: 933 (ouch!) December 4: 931 December 5: 934 (ouch, again!) December 5: 930 Activities on the trac system yesterday: New tickets 4 Tickets closed 5 Tickets reopened 1 Tickets changed 15 [ Some other changes happened after midnight; hence the difference between the deltas and the total # of tickets ] marshall 8 rleigh@ 3 jwellico 2 andysem 2 altsysreq@ 2 --others-- 8 So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)? -- Marshall
On 12/6/2010 9:22 AM, Marshall Clow wrote:
So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)?
I think it proves that people are too busy around the holidays for a bug sprint. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Tue, Dec 7, 2010 at 2:02 AM, Eric Niebler <eric@boostpro.com> wrote:
On 12/6/2010 9:22 AM, Marshall Clow wrote:
So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)?
I think it proves that people are too busy around the holidays for a bug sprint.
That, and/or there aren't enough people willing to look at issues and/or contribute patches to Boost. IMO, there's got to be something done about this, what exactly I don't know. Maybe better marketing of Boost? Reaching out to communities outside of Boost-devel? The guild sounds like a good thing, but I haven't seen much concrete steps going that direction yet. -- Dean Michael Berris deanberris.com
On 07/12/2010 02:36, Dean Michael Berris wrote:
On Tue, Dec 7, 2010 at 2:02 AM, Eric Niebler<eric@boostpro.com> wrote:
On 12/6/2010 9:22 AM, Marshall Clow wrote:
So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)?
I think it proves that people are too busy around the holidays for a bug sprint.
That, and/or there aren't enough people willing to look at issues and/or contribute patches to Boost.
1. There were only a limited number of library author taking part. 2. Non-library authors don't have trunk commit access. Now, the chances are most of the bugs / trac tickets are with libraries where the author isn't taking part. Now, the culture of boost discourage any commit to libraries not "owned" by oneself. Hence we have a result where there's people willing to make patches or whatever, attach it to trac, and then nothing happens. It's not very encouraging to see patches you've done during the last bug sprint 6 months ago to still be sitting in trac unapplied. KTC
On 1:59 PM, KTC wrote:
On 07/12/2010 02:36, Dean Michael Berris wrote:
On Tue, Dec 7, 2010 at 2:02 AM, Eric Niebler<eric@boostpro.com> wrote:
On 12/6/2010 9:22 AM, Marshall Clow wrote:
So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)?
I think it proves that people are too busy around the holidays for a bug sprint.
That, and/or there aren't enough people willing to look at issues and/or contribute patches to Boost.
1. There were only a limited number of library author taking part.
2. Non-library authors don't have trunk commit access. Now, the chances are most of the bugs / trac tickets are with libraries where the author isn't taking part. Now, the culture of boost discourage any commit to libraries not "owned" by oneself. Hence we have a result where there's people willing to make patches or whatever, attach it to trac, and then nothing happens. It's not very encouraging to see patches you've done during the last bug sprint 6 months ago to still be sitting in trac unapplied.
+1 I think the bug sprint emphasizes the need for Boost.Guild, and shows it's biggest risk of failure. We need a group of people willing to commit changes to various libraries. Otherwise patches languish in trac. (Or the trunk.) Bugging maintainers just doesn't work. There's been discussion about criteria for becoming a maintainer. What about criteria for staying one? Boostpro: you guys said you were willing to commit resources... what about it? I think this is where resources are most needed.
On Mon, Dec 6, 2010 at 1:02 PM, Eric Niebler <eric@boostpro.com> wrote:
On 12/6/2010 9:22 AM, Marshall Clow wrote:
So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)?
I think it proves that people are too busy around the holidays for a bug sprint.
Agreed. For me, the number of distractions seemed to double or triple. Even so, the bug sprint did get me geared up and headed in the right direction. I'm continuing to work on bugs, too. I think the bug sprints are quite valuable. Their timing, however, is critical. --Beman
Beman Dawes <bdawes@acm.org> writes:
On Mon, Dec 6, 2010 at 1:02 PM, Eric Niebler <eric@boostpro.com> wrote:
On 12/6/2010 9:22 AM, Marshall Clow wrote:
So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)?
I think it proves that people are too busy around the holidays for a bug sprint.
Agreed. For me, the number of distractions seemed to double or triple.
Same here.
I think the bug sprints are quite valuable. Their timing, however, is critical.
Agreed. I've participated in the last two, but didn't in this one because I've got too much else on. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
On Dec 7, 2010, at 4:20 AM, Beman Dawes wrote:
On Mon, Dec 6, 2010 at 1:02 PM, Eric Niebler <eric@boostpro.com> wrote:
On 12/6/2010 9:22 AM, Marshall Clow wrote:
So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)?
I think it proves that people are too busy around the holidays for a bug sprint.
[ snip ] I think the bug sprints are quite valuable. Their timing, however, is critical.
Ok - I'm hearing this from several people. We've had bug sprints in June, (early) November, June and (late) November. Basically, I've tried to schedule them for: 1) Fairly soon after a release 2) Not to conflict with BoostCon. so now, I can add a third criteria: 3) Not around the end-of-year holidays. What others? -- Marshall
On 08/12/10 00:55, Jeff Garland wrote:
On Tue, Dec 7, 2010 at 7:46 AM, Marshall Clow<mclow.lists@gmail.com> wrote:
On Dec 7, 2010, at 4:20 AM, Beman Dawes wrote:
2) Not to conflict with BoostCon.
Or perhaps we should in fact have a set of sprint sessions @ boostcon to get more folks involved.
In the same way we have the lib in a week sessions ? Maybe we could say the first day, ehre is the state of libs, make group, pick a lib per group and starts the hack'a'thon ?
On Dec 7, 2010, at 4:20 AM, Beman Dawes wrote:
2) Not to conflict with BoostCon.
Or perhaps we should in fact have a set of sprint sessions @ boostcon to get more folks involved.
In the same way we have the lib in a week sessions ? Maybe we could say the first day, ehre is the state of libs, make group, pick a lib per group and starts the hack'a'thon ?
I like that idea. Marshall: is that something you would like to pursue? Regards Hartmut --------------- http://boost-spirit.com
On 1:59 PM, Hartmut Kaiser wrote:
On Dec 7, 2010, at 4:20 AM, Beman Dawes wrote:
2) Not to conflict with BoostCon.
Or perhaps we should in fact have a set of sprint sessions @ boostcon to get more folks involved. In the same way we have the lib in a week sessions ? Maybe we could say the first day, ehre is the state of libs, make group, pick a lib per group and starts the hack'a'thon ? I like that idea. Marshall: is that something you would like to pursue?
What if you put big gold stars on their name-tag proportional to the bugs they've fixed before they arrive. And recognize the top five with fanfare. How many attend BoostCon?
Jim Bell wrote:
On 1:59 PM, Hartmut Kaiser wrote:
On Dec 7, 2010, at 4:20 AM, Beman Dawes wrote:
2) Not to conflict with BoostCon.
Or perhaps we should in fact have a set of sprint sessions @ boostcon to get more folks involved. In the same way we have the lib in a week sessions ? Maybe we could say the first day, ehre is the state of libs, make group, pick a lib per group and starts the hack'a'thon ? I like that idea. Marshall: is that something you would like to pursue?
What if you put big gold stars on their name-tag proportional to the bugs they've fixed before they arrive. And recognize the top five with fanfare.
How many attend BoostCon?
About 100 -- of course many of them are folks like me who are too busy to fix bugs in their own lib :-( Anyway, I believe this was suggested as a possible Library in a Week topic, although I'd worry that no one would get up in the morning to do bug fixes. I think the recognition idea is good -- maybe we could even have some awards (t-shirts or other swag) for the most prolific bug fixers. Jeff
On Dec 8, 2010, at 4:22 AM, Hartmut Kaiser wrote:
On Dec 7, 2010, at 4:20 AM, Beman Dawes wrote:
2) Not to conflict with BoostCon.
Or perhaps we should in fact have a set of sprint sessions @ boostcon to get more folks involved.
In the same way we have the lib in a week sessions ? Maybe we could say the first day, ehre is the state of libs, make group, pick a lib per group and starts the hack'a'thon ?
I like that idea. Marshall: is that something you would like to pursue?
I'm concerned that this would take time away from the other sessions at Boostcon. It's already a pretty full week. What do other people think? -- Marshall
On 21 December 2010 13:59, Marshall Clow <mclow.lists@gmail.com> wrote:
I'm concerned that this would take time away from the other sessions at Boostcon. It's already a pretty full week.
What do other people think?
This concerns me too. While I've attended the Library in a Week sessions, I haven't actively participated in them for precisely that reason. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On 1:59 PM, Nevin Liber wrote:
On 21 December 2010 13:59, Marshall Clow <mclow.lists@gmail.com> wrote:
I'm concerned that this would take time away from the other sessions at Boostcon. It's already a pretty full week.
What do other people think?
This concerns me too.
While I've attended the Library in a Week sessions, I haven't actively participated in them for precisely that reason.
More motivation to shift it to an accolade awarded at Boostcon? Have all Boostcon literature mention it prominently?
On 23 December 2010 08:31, Jim Bell <Jim@jc-bell.com> wrote:
On 21 December 2010 13:59, Marshall Clow <mclow.lists@gmail.com> wrote:
I'm concerned that this would take time away from the other sessions at Boostcon.
More motivation to shift it to an accolade awarded at Boostcon?
I must be dense today; how does this address the concern that it takes time away from other sessions at BoostCon? Also, what is the value-added to a BoostCon attendee for participating in a Bug Sprint (instead of staying home and participating)? It could be something as simple as getting to work face to face with others on fixing bugs, but to make that happen successfully, someone passionate about it has to volunteer to organize it. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On 23 December 2010 08:31, Jim Bell <Jim@jc-bell.com> wrote:
On 21 December 2010 13:59, Marshall Clow <mclow.lists@gmail.com> wrote:
I'm concerned that this would take time away from the other sessions at Boostcon. More motivation to shift it to an accolade awarded at Boostcon?
I must be dense today; how does this address the concern that it takes time away from other sessions at BoostCon?
My thinking: bug fixing wouldn't happen at BoostCon. But at some session(s), give awards for the best bug-sprinters--most bugs fixed over the entire year (not intruding much on the session--5 minutes?). Maybe separate awards for maintainer and non-maintainer. Maybe 1st, 2nd, 3rd place. (Gold, silver, bronze.)
Marshall Clow-2 wrote:
Well, the bug sprint is over. [ But that doesn't mean you have to stop fixing bugs if you don't want to! ]
So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)?
Hi, I hope there will be a next time. I find we need this kind of sprints to decrease the number of tickets. As, most of the participants can not commit the changes, in the next Bug sprint, I would track in the daily reports the number of Patches. IMO a good measure of a good/bad Bug sprint should be the number of open Bugs, not the number of open tickets. In particular I will not count the Support, Task or Feature Requests tickets as they are not associated to a bad behavior of the libraries. I purpose now that we request the authors/maintainers to manage with the ~100 patches that are "ready" on the Trac. If the author/maintainer considers that the patch is not valid or incomplete I purpose that them move it to Bug or Feature request with a clear explanation of what is missing. In this way the Patches tickets will account for the tickets that the author maintainer should merge as soon as possible. I would say also that Bugs associated to toolsets that are not run neither on the trunk nor the release branches, should not be considered as Bugs, as the library has not been tested with this toolset in a regular base. People wanting support for a toolset should ensure by himself that this toolset belongs to the testing toolsets for the trunk or the release branches. In addition to the Bug Sprint I would like we start an open activity that would add more regression tests. People could propose test patches under another ticket category (why not Test). It is clear to me that a better coverage of the Boost libraries should increase its quality. Let me know what do you think of these points. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Bug-Sprint-Final-report-for-the-late-2010... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 1:59 PM, Vicente Botet wrote:
Marshall Clow-2 wrote:
Well, the bug sprint is over. [ But that doesn't mean you have to stop fixing bugs if you don't want to! ]
So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)?
...I would track in the daily reports the number of Patches.
+1
IMO a good measure of a good/bad Bug sprint should be the number of open Bugs, not the number of open tickets. In particular I will not count the Support, Task or Feature Requests tickets as they are not associated to a bad behavior of the libraries.
+1
[...]
In addition to the Bug Sprint I would like we start an open activity that would add more regression tests. [...]
I think resources should first be spent making the existing regressions pass. And more regressions should flow out of valid bug reports. (See Boost.Guild ticket handling <http://jc-bell.com/contributions/boost-guild/boost-ticket-handling>.)
On 12/07/2010 04:52 PM, Vicente Botet wrote:
Marshall Clow-2 wrote:
Well, the bug sprint is over. [ But that doesn't mean you have to stop fixing bugs if you don't want to! ]
So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)?
Hi,
I hope there will be a next time. I find we need this kind of sprints to decrease the number of tickets.
As a long distance runner, I'd argue that sprints take you only a few meters and than you have to stop and catch your breath. Measured over a longer period of time, continuous jogging or even walking will take you much further. I therefore wonder if there are ways to make it more attractive to fix bugs in general. Not only during bug sprints? Maybe we could have some "Bug Fixer of the Month" Award? Or let contributors appear in the release notes? I don't know. In Web2.0, you are the coolest guy if your blogs are referenced/read/whatever by the most people or if you have the most friends, etc. In the boost community maybe you could gain a certain standing by fixing bugs or contributing test cases... Regards, Roland
On 12/7/2010 1:44 PM, Roland Bock wrote:
On 12/07/2010 04:52 PM, Vicente Botet wrote:
Marshall Clow-2 wrote:
Well, the bug sprint is over. [ But that doesn't mean you have to stop fixing bugs if you don't want to! ]
So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)?
Hi,
I hope there will be a next time. I find we need this kind of sprints to decrease the number of tickets.
As a long distance runner, I'd argue that sprints take you only a few meters and than you have to stop and catch your breath. Measured over a longer period of time, continuous jogging or even walking will take you much further.
I therefore wonder if there are ways to make it more attractive to fix bugs in general. Not only during bug sprints? Maybe we could have some "Bug Fixer of the Month" Award? Or let contributors appear in the release notes?
I don't know. In Web2.0, you are the coolest guy if your blogs are referenced/read/whatever by the most people or if you have the most friends, etc. In the boost community maybe you could gain a certain standing by fixing bugs or contributing test cases...
The best way to make fixing bugs in Boost attractive is to know that once one has tested the fix and created a patch, the fix will not just sit somewhere and never be applied. Either Boost needs more people who have access to changing Boost trunk to deal with patches as they are submitted, or it needs to give access to more trusted people to update Boost trunk with patches. At the same time, if the latter happens, anybody who is given access to Boost trunk directly to apply a patch has to take responsibility in case the patch is in any way incorrect to fix it or remove it. As a programmer I would be most discouraged if a patch on which I had worked hard were never applied to fix a problem. This would induce me not to make further efforts trying to fix a product. Having been in that situation, in my last official on-site corporate job some 2+ years ago, I had much less interest in continuing my efforts to improve the buggy product(s) on which I was working. Boost is, of course, much better than the typical corporate software, but I believe the same principle applies. Programmers get a great deal of impetus and personal satisfaction in their work when they know that their efforts are being applied and they are improving a product, even in cases where they themselves may not be acknowledged.
On 12/07/2010 09:35 PM, Edward Diener wrote:
On 12/7/2010 1:44 PM, Roland Bock wrote:
On 12/07/2010 04:52 PM, Vicente Botet wrote:
Marshall Clow-2 wrote:
Well, the bug sprint is over. [ But that doesn't mean you have to stop fixing bugs if you don't want to! ]
So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)?
Hi,
I hope there will be a next time. I find we need this kind of sprints to decrease the number of tickets.
As a long distance runner, I'd argue that sprints take you only a few meters and than you have to stop and catch your breath. Measured over a longer period of time, continuous jogging or even walking will take you much further.
I therefore wonder if there are ways to make it more attractive to fix bugs in general. Not only during bug sprints? Maybe we could have some "Bug Fixer of the Month" Award? Or let contributors appear in the release notes?
I don't know. In Web2.0, you are the coolest guy if your blogs are referenced/read/whatever by the most people or if you have the most friends, etc. In the boost community maybe you could gain a certain standing by fixing bugs or contributing test cases...
The best way to make fixing bugs in Boost attractive is to know that once one has tested the fix and created a patch, the fix will not just sit somewhere and never be applied. Either Boost needs more people who have access to changing Boost trunk to deal with patches as they are submitted, or it needs to give access to more trusted people to update Boost trunk with patches. At the same time, if the latter happens, anybody who is given access to Boost trunk directly to apply a patch has to take responsibility in case the patch is in any way incorrect to fix it or remove it. That would certainly be a requirement.
And sure, it gives some satisfaction to see the patch applied, but I think we could add some more incentive by publishing some facts about closed bugs, giving contributors their moment(s) of fame. Regards, Roland
Roland Bock wrote:
On 12/07/2010 04:52 PM, Vicente Botet wrote:
Marshall Clow-2 wrote:
Well, the bug sprint is over. [ But that doesn't mean you have to stop fixing bugs if you don't want to! ]
So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)?
Hi,
I hope there will be a next time. I find we need this kind of sprints to decrease the number of tickets.
As a long distance runner, I'd argue that sprints take you only a few meters and than you have to stop and catch your breath. Measured over a longer period of time, continuous jogging or even walking will take you much further.
If any boost libraries are a long distance from being bug free then we have much bigger problems. I think that as most libraries are only a few meters from closing all their open tickets at any given time a bug sprint is a great way to get a lot of tickets closed in a hurry and then we can all stop, catch our breath and go back to doing things that pay the bills. I like the bug sprints because it reminds me to check the trac. I have a zero tolerance policy for open bugs on anything I maintain, but bugs can sit unnoticed if I don't get email letting me know there is a problem and I don't check the trac often since my expectation is that it should be empty. When there is a bug sprint I check the trac to see if I can contribute just in case a bug was filed that I wasn't aware of. Regards, Luke
On 1:59 PM, Simonson, Lucanus J wrote:
Roland Bock wrote:
On 12/07/2010 04:52 PM, Vicente Botet wrote:
Marshall Clow-2 wrote:
Well, the bug sprint is over. [ But that doesn't mean you have to stop fixing bugs if you don't want to! ]
So - what did people think went well during the bug sprint? What went poorly?[...] [...] As a long distance runner, I'd argue that sprints take you only a few meters and than you have to stop and catch your breath. Measured over a longer period of time, continuous jogging or even walking will take you much further.
That fits with my Boost.Guild philosophy: many people, each contributing a little.
If any boost libraries are a long distance from being bug free then we have much bigger problems. I think that as most libraries are only a few meters from closing all their open tickets at any given time [...]
Have you studied the regression matrix? There seem to be quite a few failures on it. I perceive the distance to be longer, and that we do have bigger problems.
On 12/08/2010 04:51 AM, Jim Bell wrote:
On 1:59 PM, Simonson, Lucanus J wrote:
Roland Bock wrote:
On 12/07/2010 04:52 PM, Vicente Botet wrote:
Marshall Clow-2 wrote:
Well, the bug sprint is over. [ But that doesn't mean you have to stop fixing bugs if you don't want to! ]
So - what did people think went well during the bug sprint? What went poorly?[...]
[...]
As a long distance runner, I'd argue that sprints take you only a few meters and than you have to stop and catch your breath. Measured over a longer period of time, continuous jogging or even walking will take you much further.
That fits with my Boost.Guild philosophy: many people, each contributing a little.
Yes, the question is how to attract people to contribute? And, as Edward pointed out, make sure their contributions are actually merged into trunk?
If any boost libraries are a long distance from being bug free then we have much bigger problems. I think that as most libraries are only a few meters from closing all their open tickets at any given time [...]
Have you studied the regression matrix? There seem to be quite a few failures on it. I perceive the distance to be longer, and that we do have bigger problems.
+1 Regards, Roland
participants (16)
-
Anthony Williams -
Beman Dawes -
Dean Michael Berris -
Edward Diener -
Eric Niebler -
Hartmut Kaiser -
Jeff Garland -
Jeff Garland -
Jim Bell -
joel falcou -
KTC -
Marshall Clow -
Nevin Liber -
Roland Bock -
Simonson, Lucanus J -
Vicente Botet