Predicting Re-opened Bugs: A Case Study on the Eclipse Project

Shihab, Emad; Ihara, Akinori; Kamei, Yasutaka; Ibrahim, Walid; Ohira, Masaichi; Adams, Bram; Hassan, Ahmed E.; Matsumoto, Kenichi

doi:10.1109/wcre.2010.36

Cited by 77 publications

(69 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Unclassified

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%

“…Several approaches [1], [7], [19]- [24] exist in this topic. For instance, Anvik et al [19], [20] proposed an approach to assign a bug to an appropriate developer based on past bug reports with natural language processing.…”

Section: Re-opening and Reassigned Bugsmentioning

confidence: 99%

“…Jeong et al [1] also tried to establish a method for the bug assignment based on a social graph which reflects on social relationships among developers in the bug assignment. Other approaches involve in achieving better understandings on why reassignment occurs many times [23] and in creating a method to predict which bugs will be reopened or get fixed without being reopened [7], [24].…”

Section: Re-opening and Reassigned Bugsmentioning

confidence: 99%

“…Some of them also perform other tasks including bug resolution and bug reports management on the bug tracking system. Therefore, committer's activities in the past are recorded in repositories of such the systems which are used by many researchers as rich information sources to test a hypothesis [4], create a prediction model [7], or performs statistical analysis [25].…”

Section: Committer's Activities In the Bug Fixing Processmentioning

confidence: 99%

See 3 more Smart Citations

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.

Self Cite

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%

Section: Re-opening and Reassigned Bugsmentioning

confidence: 99%

Section: Re-opening and Reassigned Bugsmentioning

confidence: 99%

Section: Committer's Activities In the Bug Fixing Processmentioning

confidence: 99%

See 2 more Smart Citations

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.

Self Cite

View full text Add to dashboard Cite

show abstract

“…To measure the performance of Sim TagCombine , we use top-K prediction accuracies, which follows some previous studies [21][22][23][24] . Top-K prediction accuracy is the percentage of questions in the test set where their ground truth similar questions are ranked in the top-k positions in the returned ranked lists of similar questions.…”

Section: How Can We Use the Tags Recommended By Tagcombine?mentioning

confidence: 99%

TagCombine: Recommending Tags to Contents in Software Information Sites

Wang

Xia

2015

J. Comput. Sci. Technol.

View full text Add to dashboard Cite

Nowadays, software engineers use a variety of online media to search and become informed of new and interesting technologies, and to learn from and help one another. We refer to these kinds of online media which help software engineers improve their performance in software development, maintenance, and test processes as software information sites. In this paper, we propose TagCombine, an automatic tag recommendation method which analyzes objects in software information sites. TagCombine has three different components: 1) multi-label ranking component which considers tag recommendation as a multi-label learning problem; 2) similarity-based ranking component which recommends tags from similar objects; 3) tag-term based ranking component which considers the relationship between different terms and tags, and recommends tags after analyzing the terms in the objects. We evaluate TagCombine on four software information sites, Ask Different, Ask Ubuntu, Freecode, and Stack Overflow. On averaging across the four projects, TagCombine achieves recall@5 and recall@10 to 0.619 8 and 0.762 5 respectively, which improves TagRec proposed by Al-Kofahi et al. by 14.56% and 10.55% respectively, and the tag recommendation method proposed by Zangerle et al. by 12.08% and 8.16% respectively.

show abstract

An empirical study of faults in late propagation clone genealogies

Barbour

Khomh

Zou

2013

J Software Evolu Process

View full text Add to dashboard Cite

SUMMARYTwo similar code segments, or clones, form a clone pair within a software system. The changes to the clones over time create a clone evolution history. In this work, we study late propagation, a specific pattern of clone evolution. In late propagation, one clone in a clone pair is modified, causing the clone pair to diverge. The code segments are then reconciled in a later commit. Existing work has established late propagation as a clone evolution pattern and suggested that the pattern is related to a high number of faults. In this study, we examine the characteristics of late propagation in three long-lived software systems using the SIMIAN ( Simon Harris, Victoria, Australia, http://www.harukizaemon.com/simian), CCFINDER, and NICAD (Software Technology Laboratory, Queen's University, Kingston, ON, Canada) clone detection tools. We define eight types of late propagation and compare them to other forms of clone evolution. Our results not only verify that late propagation is more harmful to software systems but also establish that some specific types of late propagations are more harmful than others. Specifically, two types are most risky: (1) when a clone experiences diverging changes and then a reconciling change without any modification to the other clone in a clone pair; and (2) when two clones undergo a diverging modification followed by a reconciling change that modifies both the clones in a clone pair. We also observe that the reconciliation in the former case is more prone to faults than in the latter case. We determine that the size of the clones experiencing late propagation has an effect on the fault proneness of specific types of late propagation genealogies. Lastly, we cannot report a correlation between the delay of the propagation of changes and its faults, as the fault proneness of each delay period is system dependent.

show abstract

Predicting Re-opened Bugs: A Case Study on the Eclipse Project

Cited by 77 publications

References 29 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

TagCombine: Recommending Tags to Contents in Software Information Sites

An empirical study of faults in late propagation clone genealogies

Contact Info

Product

Resources

About