Volunteer for research project?

[H. S. Teoh]

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