Categorizing and predicting reopened bug reports to improve software reliability

Software maintenance takes two thirds of the life cycle of the project. Bug fixes are an important part of software maintenance. Bugs are tracked using online tools like Bugzilla. It has been noted that around 10% of fixes are buggy fixes. Many bugs are documented as fixed when they are not actually fixed, thus reducing the reliability of the software. The overlooked bugs are critical as they take more resources to fix when discovered, and since they are not documented, the reality is that defect are still present and reduce reliability of software. There have been very few studies in understanding these bugs. The best way to understand these bugs is to mine software repositories. To generalize findings we need a large number of bug information and a wide category of software projects. To solve the problem, a web crawler collected around a million bug reports from online repositories, and extracted important attributes of the bug reports. We selected four algorithms: Bayesian network, NaiveBayes, C4.5 decision tree, and Alternating decision tree. We achieved a decent amount of accuracy in predicting reopened bugs across a wide range of projects. Using AdaBoost, we analyzed the most important factors responsible for the bugs and categorized them in three categories of reputation of committer, complex units, and insufficient knowledge of defect

Good or Bad Committers? A Case Study of Committers ’ Cautiousness and the Consequences on the Bug Fixing Process in the Eclipse Project

Abstract—There 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 software repository play a major role in this process and hold a key to the successfulness of the project. In this work, we have observed each committer activities from the Eclipse-Platform bug tracking system and version archives. Despite the importance of committer’s activities, we suspect that sometimes committers can make some mistakes, which have a negative consequence to the bug fixing process. Our research focus on studying the consequences of each committer’s activities to this process. We collected each committer’s history data and evaluated each of them by comparing the more cautiousness to less cautiousness committers. Then we looked deeper into each committer’s characteristics to see the reasons why some committers tend to make a mistake more than the others. From our results, we would like to make a humbly suggestion to the OSS’s committers to be aware of their importance to the projects and be cautious before doing their jobs. Keywords-open source software (OSS); committer; bug fixing process I