On Fri, Feb 22, 2013 at 06:51:53AM +0100, Maxim Fomin wrote: > On Thursday, 21 February 2013 at 07:03:08 UTC, Brad Roberts wrote: > >Would any of you be interested in helping out (read that as "doing") > >a research / data mining project for us? I'd love to take all of the > >regressions this year (or for the last year, or whatever period of > >time can be reasonably accomplished) and track them back to which > >commit introduced each of them (already done for some of them). From > >there, I'd like to see what sort of correlations can be found. Is > >there a particular area of code that's responsible for them. Is > >there a particular feature (spread across a lot of files, maybe) > >that's responsible. Etc. > > > >Maybe it's all over the map. Maybe it will highlight one or a few > >areas to take a harder look at. > > > >Anyone interested? > > > >Thanks, > >Brad > > It sounds interesting, but what are you expecting to found? And how > much are you sure you can found something? I would expect that often > code which fixes some feature breaks the same feature in another > aspect of functioning which is quite obvious. Sometimes one code > relies implicitly on functioning of other code, so when you change the > the latter, the former stops working correctly. You provide example > with spreading across several files - how does knowing this helps in > reducing regressions?
I would think he's referring to issues that are filed in the bugtracker. Obviously, we have no way of knowing if a code change broke something if nobody found any bug afterwards! So I'm thinking it's probably a matter of going through the regression bugs in the bugtracker, and making test cases to reproduce them, and then use git bisect to figure out which commit introduced the problem. T -- Public parking: euphemism for paid parking. -- Flora
