Bug sprint aftermath questions.
Now the bug sprint is over - I have a few questions..... * Was the bug sprint worth doing? * If so, is it worth doing again? How soon? Regularly? How often? * What worked really well? * What didn't work well? I'm also looking for general comments.... Facts: * We went from 797 open tickets to 706. (that's a change of 12%) * A lot of very old tickets were dealt with; the oldest Trac ticket is now from 2005 (instead of 2001). * There's still several tickets that have patches waiting to be applied. * The Trac system had a few problems ("locked database") and is still having spam problems, but worked reasonably well. -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
* Was the bug sprint worth doing? Definitively
* If so, is it worth doing again? How soon? Regularly? How often? The question, why not ding this as a background task ?
* We went from 797 open tickets to 706. (that's a change of 12%) I think it's already a great thing.
* There's still several tickets that have patches waiting to be applied. Problem is that it seems some lib maintainer are just not around anymore.
joel-75 wrote:
* There's still several tickets that have patches waiting to be applied. Problem is that it seems some lib maintainer are just not around anymore.
I agree. It is not very encouraging to try to solve issues, add tests, post patches when the maintainer is just ignoring them. Vicente -- View this message in context: http://www.nabble.com/Bug-sprint-aftermath-questions.-tp23935224p23942399.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
Vicente Botet Escriba wrote:
I think the solution might be to have a process where libraries that sit unmaintained for some period of time can be adopted by someone else. (Not that people necessarily want to do maintain someone's library, but if someone using the library is applying patches on their local copy anyway, maybe they'd like to be the maintainer.) --Jeffrey Bosboom
on Tue Jun 09 2009, Jeffrey Bosboom <jbosboom-AT-uci.edu> wrote:
That actually has happened in the past; I'd like to formalize that process. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Gottlob Frege wrote: libraries requiring expertise need to be followed by experts, othere like numeric or such may be handed to knowledgeable people but not necessary to the original author. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
It helps if there is at least nominally a formal maintainer to: * Handle bug reports for that library. * Keep track of regression reports for that library (for example check it's status when new compilers are released and get tested). * Handle merging changes to the release branch once they are stable. John.
On Tue, Jul 7, 2009 at 4:52 AM, John Maddock<john@johnmaddock.co.uk> wrote:
I'm thinking more about what tends to happen in companies with lots of employees and code: - original author or last maintainer 'gets hit by a bus' (leaves) - code sits for quite a while because it basically works, so no need to touch - eventually someone (typically a new guy) manages to find some obscure bug in it (or maybe when moving to a new compiler, etc) - new guy asks around (ie emails an internal list or bunch of devs) about the bug (hoping someone knows the fix) - lots of people are 'familiar' with the code but no one 'owns' it anymore - new guy fixes it because he needs a fix! - new guy does LOTS of testing - hopefully lots of good test code already exists - new guy asks around if the fix looks good or if it might cause unknown repercussions (shouldn't be if good test cases!) - people familiar with code take a peak and give yes/no - new guy checks in fix if all agree ie *group* oversight + new guy code = maintainer *for this fix* And either new guy picks it up and eventually becomes the real maintainer, or it just sits until the next problem stumbled upon by the next 'new guy'. For boost this means - boost email list gives oversight - whomever finds/fixes bug supplies code and "real work" only questions (because I am not familiar with the mechanics) - is how the new guy gets access to do the checkins - is there more work that I left out? - is there work later on after this bug has been fixed, or is there 'maintenance' even for working code? - does this put too much burden on the core boost guys (ie they will probably need to do the oversight, grant access, etc)? Tony
He can submit a patch and someone else can commit if he doesn't have commit priviledges.
That's the issue, it's having someone who can find the time to check the patch over and give it the yes/no vote: normally this is the library's maintainers job. We also need someone to move the patch from the Trunk to the release branch once it's been shown to be stable in the full regression tests. John.
Marshall Clow wrote:
I wasn't able to join the sprint, but I've since pledged something else: do one trac item a day. It does not have to be complete (some items require lots of work), just give some time for it per day. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
participants (10)
-
Beman Dawes -
David Abrahams -
Gottlob Frege -
Jeffrey Bosboom -
joel -
Joel de Guzman -
Joel.Falcou＠lri.fr
-
John Maddock -
Marshall Clow -
Vicente Botet Escriba