When do changes induce fixes?

By Jacek Sliwerski, Thomas Zimmermann, Andreas Zeller. ACM SIGSOFT Softw. Eng. Notes, 2005

1,095 citations recorded by the source corpus.

Subfields: Artificial Intelligence, Computer Networks and Communications, Information Systems

View Paper: https://www.semanticscholar.org/paper/9784038a293df294d955c0edd72ee37a4bfe8705

How researchers see this paper

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

In Artificial Intelligence

In Computer Networks and Communications

In Information Systems

Citations in the corpus

Automatic Identification of Bug-Introducing Changes (2006, methodology): “original SZZ algorithm [16] (P) and by the approach (steps 1-5) proposed in this paper (R).”
Predicting vulnerable software components (2007, methodology): “[30] and extends the approaches introduced by Fischer et al.”
A large-scale empirical study of just-in-time quality assurance (2013, methodology): “Other heuristics to confirm whether a change is really a defect-fix change are discussed elsewhere [57].”
It's not a bug, it's a feature: How misclassification impacts bug prediction (2013, background): “Taking the blame, other typical examples with one of us as co-authors are: [5], [6], [7], [8], [9].”
Is it a bug or an enhancement?: a text-based approach to classify change requests (2008, methodology): “[17] introduced a refined approach to identify whether a change induced a bug fix.”
Classifying Software Changes: Clean or Buggy? (2008, methodology): “Two approaches are used for this step: searching for keywords such as “Fixed” or “Bug” [32] and searching for references to bug reports like “#42233” [6], [7], [47].”
Predicting Defects for Eclipse (2007, methodology): “This approach was previously used in research [3, 6, 17].”
Change Distilling:Tree Differencing for Fine-Grained Source Code Change Extraction (2007, background): “classify changes according to whether they induced a fix [34], that is, changes that lead to problems.”
Mining version histories to guide software changes (2004, background): “Furthermore, one can link changes to bug databases to identify fix-inducing changes [29].”
Mining metrics to predict component failures (2006, background): “The ke y idea is that one can map problems (in the bug database) to fixes (in the version database) and thus to those locations in th e code that caused the problem [9, 12, 20].”
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.”
PyDriller: Python framework for mining software repositories (2018, methodology): “We use SZZ [17] to retrieve the commits where the bug was introduced, as normally done in previous literature [14, 15, 20].”
On the "Naturalness" of Buggy Code (2015, methodology): “The abundant history of changes (including bug fixes) in OSS projects allows the use of standard methods [50] to find code that was implicated in bug fixes (“buggy code”).”
On the diffuseness and the impact on maintainability of code smells: a large scale empirical investigation (2017, methodology): “We relied on the SZZ algorithm (Sliwerski et al. 2005) to investigate whether there is a temporal relationship between the occurrence of a code smell and a bug induction.”
Understanding security mistakes developers make: Qualitative analysis from Build It, Break It, Fix It (2020, methodology): “This trend was uncovered by a poisson regression (appropriate for count data) [15, 67-106] we performed for issues in the Mistakes type.”
ReLink: recovering links between bugs and changes (2011, methodology): “[28] proposed to verify the links by semantic analysis.”