Identifying reasons for software changes using historic databases

By Audris Mockus, L. Votta. Proceedings 2000 International Conference on Software Maintenance, 2000

546 citations recorded by the source corpus.

Subfields: Information Systems, Software

View Paper: https://www.semanticscholar.org/paper/a61ce971a025b8fec904265f9d3e633de4f93cdb

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

In Software

Citations in the corpus

An empirical study of the impact of modern code review practices on software quality (2015, methodology): “A similar approach was used to determine defect-ﬁxing and defect-inducing changes in other work (Mockus and Votta, 2000; Hassan, 2008; Kim et al. , 2008; Kamei et al. , 2013).”
The impact of tangled code changes (2013, methodology): “For change sets referencing not only bug reports we used an automatic change purpose classification model based on the findings of Mockus and Votta [26] and Hindle et al. [13], [14] indicating that bug fixing change sets apply less change operations when compared to feature implementing change sets.”
Mining version histories to guide software changes (2004, background): “Word frequency analysis and key-word classiﬁcation of log messages can identify the purpose of changes and relate it to change size and time between changes [18].”
ReLink: recovering links between bugs and changes (2011, methodology): “For example: • The percentage of bug-fixing changes [15, 16, 21]: changes can be classified into many categories such as corrective changes (for bug fixing), adaptive changes (e.g., for accommodating new features), and perfective changes (e.g., for refactoring).”
The road ahead for Mining Software Repositories (2008, methodology): “Lexical heuristics used to determine the rationale for a change [49] would not be needed, if the User Interface of source control repository tool would permit a developer to select the purpose of a change from a drop-down menu.”
On the "Naturalness" of Buggy Code (2015, unknown): “[33], we marked a commit as a bug-fix, if the corresponding stemmed bagof-words contains at least one of the error related keywords: ‘error’, ‘bug’, ‘fix’, ‘issue’, ‘mistake’, ‘incorrect’, ‘fault’, ‘defect’, ‘flaw’, and ‘type’.”
Automatic Identification of Bug-Introducing Changes (2006, background): “To do so, one examines change log messages in two ways: searching for keywords such as "Fixed" or "Bug" [12] and searching for references to bug reports like " #42233 " [2] [4] [16].”
Quality and productivity outcomes relating to continuous integration in GitHub (2015, background): “First, given that it is common practice for developers to describe their work in commit messages, one way to reason about the rate of bugs is to identify bug-8 ﬁx commits , e.g. , by searching for defect-related keywords ( error , bug , ﬁx , etc.) in commit messages [31].”
A large scale study of programming languages and code quality in github (2014, unknown): “We further identify the bug fix commits made to individual projects by searching for error related keywords: ‘error’, ‘bug’, ‘fix’ , ‘issue’, ‘mistake’, ‘incorrect’, ‘fault’, ‘defect’ and ‘flaw’ in the commit log using a heuristic similar to that in Mockus and Votta [25].”
When do changes induce fixes? (2005, methodology): “A CVS archive also lacks information about the purpose of a change: Did it introduce a new feature or did it fix a bug? Although it is possible to identify such reasons solely with log messages [7], we combine both CVS and BUGZILLA for this step because this increases the precision of our approach.”
Dealing with noise in defect prediction (2011, methodology): “Two approaches are widely used: searching for keywords such as "Fixed" or "Bug" [14] and searching for references to bug reports like “#42233” [23] .”
An Empirical Study of API Stability and Adoption in the Android Ecosystem (2013, methodology): “Next, using a heuristic similar to Mockus and Votta [19], we identify the number of bug fixes by searching for commit messages with the keywords: bug, error, fix, and solve.”
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].”
Automatically generating commit messages from diffs using neural machine translation (2017, background): “Several authors in the related literature have observed that many code changes follow similar patterns, and have a similar high-level rationale (e.g., [38], [23]).”