Comparing fine-grained source code changes and code churn for bug prediction

Giger, Emanuel; Pinzger, Martin; Gall, Harald C.

doi:10.1145/1985441.1985456

Cited by 86 publications

(76 citation statements)

References 40 publications

(80 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Selecting Eclipse-Platform as a case study would lead to provide a useful insight on both OSS and commercial software development. At the same time, we believe that answering the following research question could contribute to improve and/or refine the results of previous studies [7]- [9] which had relied on the Eclipse-Platform's data set. © RQ: What characteristics relates to the more cautious committers?…”

Section: Introductionmentioning

confidence: 79%

Good or Bad Committers? —— A Case Study of Committer's Activities on the Eclipse's Bug Fixing Process

Jongyindee

Ohira

Ihara

et al. 2012

IEICE Trans. Inf. & Syst.

View full text Add to dashboard Cite

Anakorn JONGYINDEE †a) , Student Member, Masao OHIRA † †b) , Akinori IHARA † † †c) , and Ken-ichi MATSUMOTO † † †d) , Members SUMMARYThere are many roles to play in the bug fixing process in open source software development. A developer called "Committer", who has a permission to submit a patch into a software repository, plays a major role in this process and holds a key to the successfulness of the project. Despite the importance of committer's activities, we suspect that sometimes committers can make mistakes which have some consequences to the bug fixing process (e.g., reopened bugs after bug fixing). Our research focuses on studying the consequences of each committer's activities to this process. We collected each committer's historical data from the EclipsePlatform's bug tracking system and version control system and evaluated their activities using bug status in the bug tracking system and commit log in the version control system. Then we looked deeper into each committer's characteristics to see the reasons why some committers tend to make mistakes more than the others. IntroductionOpen Source Software (OSS) has been attracting a great deal of attention from a variety of areas as an alternative way of software use and development. As OSS has become more common and popular among us, however, OSS projects are facing with a big challenge on their quality assurance activities. Due to the growing user base, especially large OSS projects such as the Mozilla and Eclipse projects, they have receives a considerable amount of bug reports from the users on a daily basis [1] (e.g., several hundred bug reports are posted to the Bugzilla [2] database of the Mozilla project every day). OSS projects require finding an effective way of dealing with a large number of bug reports. In an OSS project, a bug is fixed through the bug fixing process [3] which starts from the process where the bug is reported in the project until patches for fixing the bug are submitted into a software repository. Each bug report in this process is passed through one or more developers who play different roles before it is closed.

show abstract

Section: Introductionmentioning

confidence: 79%

Good or Bad Committers? —— A Case Study of Committer's Activities on the Eclipse's Bug Fixing Process

Jongyindee

Ohira

Ihara

et al. 2012

IEICE Trans. Inf. & Syst.

View full text Add to dashboard Cite

show abstract

“…In scenario S5, we consider the work of a researcher focusing on variability related bugs (Abal et al 2014) and bug prediction (Giger et al 2011). The data captured by FEVER may reveal information on features involved in bug-fixing commits.…”

Section: Fever For Software Engineering Researchmentioning

confidence: 99%

FEVER: An approach to analyze feature-oriented changes and artefact co-evolution in highly configurable systems

2017

Self Cite

View full text Add to dashboard Cite

The evolution of highly configurable systems is known to be a challenging task. Thorough understanding of configuration options their relationships, and their implementation in various types of artefacts (variability model, mapping, and implementation) is required to avoid compilation errors, invalid products, or dead code. Recent studies focusing on co-evolution of artefacts detailed feature-oriented change scenarios, describing how related artefacts might change over time. However, relying on manual analysis of commits, such work do not provide the means to obtain quantitative information on the frequency of described scenarios nor information on the exhaustiveness of the presented scenarios for the evolution of a large scale system. In this work, we propose FEVER and its instantiation for the Linux kernel. FEVER extracts detailed information on changes in variability models (KConfig files), assets (preprocessor based C code), and mappings (Makefiles). We apply this methodology to the Linux kernel and build a dataset comprised of 15 releases of the kernel history. We performed an evaluation of the FEVER approach by manually inspecting the data and compared it with commits in the system's history. The evaluation shows that FEVER accurately captures feature related changes for more than 85% of the 810 manually inspected commits. We use the collected data to reflect on occurrences of co-evolution (2018) 23:905-952 in practice. Our analysis shows that complex co-evolution scenarios occur in every studied release but are not among the most frequent change scenarios, as they only occur for 8 to 13% of the evolving features. Moreover, only a minority of developers working on a given release will make changes to all artefacts related to a feature (between 10% and 13% of authors). While our conclusions are derived from observations on the evolution of the Linux kernel, we believe that they may have implications for tool developers as well as guide further research in the field of co-evolution of artefacts.Empir Software Eng

show abstract

“…While a complete overview of these approaches lies outside the scope of this paper, we provide two illustrative examples. Giger et al [16] track the semantic evolution of a software repository, in combination with a bug tracker, for bug prediction. Instead of using a line-by-line comparison they use fine-grained source code changes that contain semantic information about the changes.…”

Section: Related Workmentioning

confidence: 99%

A logic foundation for a general-purpose history querying tool

Stevens

Roover

Noguera

et al. 2014

Science of Computer Programming

View full text Add to dashboard Cite

Version control systems (VCS) have become indispensable software development tools. The version snapshots they store to provide support for change coordination and release management, effectively track the evolution of the versioned software and its development process. Despite this wealth of historical information, it has only been leveraged by tools that are dedicated to a specific task such as empirical validation of software engineering practices or fault prediction. General-purpose tool support for reasoning about the historical information stored in a version control system is limited. This paper provides a comprehensive description of a logic-based, general-purpose history query tool called Absinthe. Absinthe supports querying versioned Smalltalk system using logic queries in which quantified regular path expressions are embedded. These expressions lend themselves to specifying the properties that each individual version in a sequence of successive software versions ought to exhibit. To demonstrate the general-purpose nature of our history query tool, we use it to verify development process constraints, to identify temporal bad smells and to answer questions that developers commonly ask. Finally, we compare a query written in Absinthe to an equivalent one written in Smalltalk.

show abstract

Comparing fine-grained source code changes and code churn for bug prediction

Cited by 86 publications

References 40 publications

Good or Bad Committers? —— A Case Study of Committer's Activities on the Eclipse's Bug Fixing Process

Good or Bad Committers? —— A Case Study of Committer's Activities on the Eclipse's Bug Fixing Process

FEVER: An approach to analyze feature-oriented changes and artefact co-evolution in highly configurable systems

A logic foundation for a general-purpose history querying tool

Contact Info

Product

Resources

About