Automatic Identification of Bug-Introducing Changes

By Sunghun Kim, Thomas Zimmermann, Kai Pan, E. James Jr. Whitehead. International Conference on Automated Software Engineering, 2006

372 citations recorded by the source corpus.

Subfields: Information Systems

View Paper: https://www.semanticscholar.org/paper/1f7432f3b8cf8196dbbf46086deb65aa1bb43997

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

In Information Systems

Citations in the corpus

Accurate and Efficient Refactoring Detection in Commit History (2018, methodology): “For example, tools that identify bug-introducing changes (e.g., the widely used SZZ [47, 66, 76]) can utilize RMiner to avoid flagging changes that do not alter the program behavior (i.e., refactorings) as bug-introducing.”
The promises and perils of mining GitHub (2009, methodology): “Researchers have also used this data to create recommender systems [3], [4], [5], study evolution patterns [6], [7], [8], predict bugs [9], [10], [11], and examine collaboration [12], [13], [14].”
ReLink: recovering links between bugs and changes (2011, background): “Kim et al. found that the change classification algorithm [16] is also sensitive to the biased data [18] when the number of instances is small.”
An empirical study on the evolution of design patterns (2007, background): “Historical co-change analysis has provided new opportunities for a number of issues: predict change propagation [24, 25], observe clone [12, 15] and crosscutting concern [5] evolution, identify crosscutting concerns [4, 7], detect of logical coupling between modules [10], find common error patterns ”
The promises and perils of mining git (2009, neutral): “A. E. Housman, A Shropshire Lad”
Fix that Fix Commit: A real-world remediation analysis of JavaScript projects (2020, methodology): “Version controlling data is used to analyze the changes in a codebase and ﬁnd the vulnerability introductions [9], [15], [20].”
Dealing with noise in defect prediction (2011, methodology): “A prediction model can be used for predicting defect-proneness (buggy or clean) of different software entities, such as a component [18, 32], file [16, 19, 33] or a change [9, 11].”
Fair and balanced?: bias in bug-fix datasets (2009, positive): “[26] to identify the fix inducing changes, but use git blame to extract rework data, rather than cvs annotate.”
The road ahead for Mining Software Repositories (2008, background): “However the use and linking of data across different repositories can help in improving the quality of the data [37] and in providing practitioners with a more complete view of the project [12].”