Subject: Re: [boost] Bug sprint aftermath questions.
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2009-07-16 00:44:15
On Tue, Jul 7, 2009 at 4:52 AM, John Maddock<john_at_[hidden]> 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.
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)?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk