On Wed, Mar 2, 2011 at 4:35 PM, Platonides <[email protected]> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
