An approach to detecting duplicate bug reports using natural language and execution information

Wang, Xiaoyin; Zhang, Lu; Xie, Tao; Anvik, John; Sun, Jiang

doi:10.1145/1368088.1368151

Cited by 448 publications

(316 citation statements)

References 16 publications

Supporting

Mentioning

312

Contrasting

Unclassified

Order By: Relevance

“…In addition, conceptual information has been utilized in conjunction with evolutionary data to support several other tasks, such as assigning incoming bug reports to developers (Anvik et al 2006;Jeong et al 2009;Kagdi and Poshyvanyk 2009;Kagdi et al 2011;Kagdi et al 2012), identifying duplicate bug reports (Runeson et al 2007;Wang et al 2008), estimating time to fix incoming bugs (Weiss et al 2007) and classifying software maintenance requests (Di Lucca et al 2002). Finally, we conducted a comprehensive literature survey on MSR approaches during the prologue of this work ).…”

Section: Evolutionary Information In Software Repositoriesmentioning

confidence: 99%

Integrating conceptual and logical couplings for change impact analysis in software

2012

View full text Add to dashboard Cite

The paper presents an approach that combines conceptual and evolutionary techniques to support change impact analysis in source code. Conceptual couplings capture the extent to which domain concepts and software artifacts are related to each other. This information is derived using Information Retrieval based analysis of textual software artifacts that are found in a single version of software (e.g., comments and identifiers in a single snapshot of source code). Evolutionary couplings capture the extent to which software artifacts were co-changed. This information is derived from analyzing patterns, relationships, and relevant information of source code changes mined from multiple versions in software repositories. The premise is that such combined methods provide improvements to the accuracy of impact sets compared to the two individual approaches.A rigorous empirical assessment on the changes of the open source systems Apache httpd, ArgoUML, iBatis, KOffice, and jEdit is also reported. The impact sets are evaluated at the file and method levels of granularity for all the software systems considered in the empirical evaluation.The results show that a combination of conceptual and evolutionary techniques, across several cutoff points and periods of history, provides statistically significant improvements in accuracy over either of the two techniques used independently. Improvements in F-measure values of up to 14%(from 3% to 17%) over the conceptual technique in ArgoUML at the method granularity, and up to 21% over the evolutionary technique in iBatis (from 9% to 30%) at the file granularity were reported.

show abstract

Section: Evolutionary Information In Software Repositoriesmentioning

confidence: 99%

Integrating conceptual and logical couplings for change impact analysis in software

2012

View full text Add to dashboard Cite

show abstract

“…Unfortunately, in practice the triage process is mostly manual, and requires triagers with a good understanding of the project history. Consequently, researchers have sought ways to automatically suggest which new bug reports might be related to previously reported bugs using a variety of techniques, such as performing textual analysis of the free form text, looking for commonly recurring error messages, noting which API elements may be involved, and using machine learning techniques [13,14].…”

Section: The Problem Of Software Development Provenancementioning

confidence: 99%

Understanding software artifact provenance

Godfrey

2015

Science of Computer Programming

View full text Add to dashboard Cite

In a well designed software system, units of related functionality are organized into modules and classes, which are in turn arranged into inheritance trees, package hierarchies, components, libraries, frameworks, and services. The trade-offs between simplicity versus flexibility and power are carefully considered, and interfaces are designed that expose the key functional properties of a component while hiding much of the complexity of the implementation details. However, over time the design integrity of a well-engineered system tends to decay as new features are added, as new quality attributes are emphasized, and as old architectural knowledge is lost when experienced development personnel shift to new jobs. Consequently, as developers and as users we often find ourselves looking at a piece of functionality or other design artifact and wondering, "Why is this here?" That is, we would like to examine the provenance of an artifact to understand its history and why it is where it is within the current design of the system.In this brief paper, we sketch some of the dimensions of the broad problem of extracting and reasoning about the provenance of software development artifacts. As a motivating example, we also describe some recent related work that uses hashing to quickly and accurately identify version information of embedded Java libraries.Keywords: Software artifact provenance, software analytics, code cloning Paul, it is easy to be impressed by your body of work at a distance. There are so many important and well-cited papers over many years, and the tools and techniques you and your group have contributed have had concrete and demonstrable impact on the research community. But when I spent my sabbatical at CWI, I learned an awful lot from you about running a research group, and getting the best out of talented people. You make it seem so easy and effortless, although I know it is neither. Your management style is low key and encouraging, yet the yield is so high. Perhaps most importantly, I have seen how the young researchers you supervise -many of whom go on to careers in industry -come away with justifiable pride in their efforts, an understanding of exactly how their work fits into the grand scheme of things, and a strong belief in the value of research itself. Surely this is the right way to build an ongoing, vibrant, and collegial community of scientists, engineers, and practitioners.

show abstract

“…To avoid duplicate bugs in BTS, several studies [15]- [18] have tried to detect duplicate bug reports automatically. For example, Wang et al [18] present an approach to detect duplicate bugs based on a natural language processing techniques.…”

Section: Duplicate Bug Detectionmentioning

confidence: 99%

“…For example, Wang et al [18] present an approach to detect duplicate bugs based on a natural language processing techniques.…”

Section: Duplicate Bug Detectionmentioning

confidence: 99%

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

An approach to detecting duplicate bug reports using natural language and execution information

Cited by 448 publications

References 16 publications

Integrating conceptual and logical couplings for change impact analysis in software

Integrating conceptual and logical couplings for change impact analysis in software

Understanding software artifact provenance

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

Contact Info

Product

Resources

About