On Wed, Mar 2, 2011 at 4:35 PM, Platonides <Platonides(a)gmail.com> wrote:
Rob Lanphier wrote:
I'd like to add something to the great
suggestions that have already
come in. Since you're already doing daily updates and seeing the
breakage, you already know within 50-60 revisions of where the
breakage is likely to be. It may only take 6-7 extra checkouts to
narrow it down to a specific revision doing a binary search through
the previous day's checkins, even without an informed guess on which
file or function is the likely suspect and including extensions. If
you narrow it down to just core (not extensions), that's roughly 20
checkins a day, so 4-5 extra checkouts should do the trick. Any
little bit of debugging like this is greatly appreciated!
That would be nice, of course. But we shouldn't demand to debug the
problem to people which is already doing us a favour by detecting them.
Just a bug report like: "Foo broke in last 24h"
"Updating from r12345 to r54321 the foo links are now like bar." would
be extremely useful, as that bug will be easy to resolve just in time
(even if it's a revert), as opposed to handling a bug which has been
there for a long time.
Oh, sure. It could be that someone like Huib identifies a problem
range, and someone else actually narrows it down to a specific commit.
I guess I should have explicitly cast the net out wider for the
second part. The second part doesn't require a deep knowledge of the
codebase, so it's an activity that someone just getting started can do
to help out.
Those 'fast' bugs are also good candidates for
the weekly sprints.
Yup, they certainly are.
Rob