Bug sprint aftermath questions.

[Marshall Clow]

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@...>

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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Joel Falcou-3]

> * 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vicente Botet Escriba]

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

[John Maddock]

>>> * 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.

Can we maintain a list of problem cases somewhere?   Sort of like a list of
pending items?  If so we could have a second sprint... or maybe more of a
jog really... where some experienced Boosters could review and commit as
required.

John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Joel Falcou-3]

John Maddock wrote:
> Can we maintain a list of problem cases somewhere?   Sort of like a
> list of pending items?  If so we could have a second sprint... or
> maybe more of a jog really... where some experienced Boosters could
> review and commit as required.
I'm all for such  thing


--
___________________________________________
Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : [phone]


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jeffrey Bosboom]

Vicente Botet Escriba wrote:

>
>
> 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

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Beman Dawes]

On Tue, Jun 9, 2009 at 12:21 PM, John Maddock<john@...> 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.
>
> Can we maintain a list of problem cases somewhere?   Sort of like a list of
> pending items?  If so we could have a second sprint... or maybe more of a
> jog really... where some experienced Boosters could review and commit as
> required.

Yes, something along those lines might be very useful.

--Beman
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Joel de Guzman-2]

Marshall Clow wrote:
> 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....

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Abrahams-3]

on Tue Jun 09 2009, Jeffrey Bosboom <jbosboom-AT-uci.edu> wrote:

> Vicente Botet Escriba wrote:
>>
>>
>> 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
>
> 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.)

That actually has happened in the past; I'd like to formalize that
process.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gottlob Frege]

On Tue, Jun 9, 2009 at 2:53 PM, Jeffrey Bosboom<jbosboom@...> 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

Small question possibly big discussion:
   Do all libraries need a specific maintainer?

Tony
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Joel Falcou-3]

Gottlob Frege wrote:
> Small question possibly big discussion. Do all libraries need a
> specific maintainer?
I agree. As much as things like ASIO, thread and other high-end
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 : [phone]


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Maddock]

>> Small question possibly big discussion. Do all libraries need a
>> specific maintainer?
> I agree. As much as things like ASIO, thread and other high-end
> 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.

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gottlob Frege]

On Tue, Jul 7, 2009 at 4:52 AM, John Maddock<john@...> wrote:

>>> Small question possibly big discussion. Do all libraries need a
>>> specific maintainer?
>>
>> I agree. As much as things like ASIO, thread and other high-end
>> 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.
>
> 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.

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Maddock]

> 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

He can submit a patch and someone else can commit if he doesn't have commit
priviledges.

> - 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)?

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost