Re: [boost] Bug sprint aftermath questions.

Subject: Re: [boost] Bug sprint aftermath questions.
From: John Maddock (john_at_[hidden])
Date: 2009-07-16 04:25:56

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