%0 Conference Paper %B Proceedings of the 2008 international working conference on Mining software repositories %D 2008 %T Understanding bug fix patterns in verilog %A Sudakrishnan, Sangeetha %A Madhavan, Janaki %A Whitehead,Jr., E. James %A Renau, Jose %K bug fixing %K error classification %K hdl %K verilog %K VHDL %X Today, many electronic systems are developed using a hardware description language, a kind of software that can be converted into integrated circuits or programmable logic devices. Like traditional software projects, hardware projects have bugs, and significant developer time is spent fixing them. A useful first step toward reducing bugs in hardware is developing an understanding of the frequency of different types of errors. Once the most common types are known, it is then possible to focus attention on eliminating them. As most hardware projects use software configuration management repositories, these can be mined for the textual bug fix changes. In this project, we analyze the bug fix history of four hardware projects written in Verilog and manually define 25 bug fix patterns. The frequency of each bug type is then computed for all projects. We find that 29 -- 55% of the bug fix pattern instances in Verilog involve assignment statements, while 18 -- 25% are related to if statements. %B Proceedings of the 2008 international working conference on Mining software repositories %S MSR '08 %I ACM %C New York, NY, USA %P 39–42 %@ 978-1-60558-024-1 %U http://doi.acm.org/10.1145/1370750.1370761 %R http://doi.acm.org/10.1145/1370750.1370761 %> https://flosshub.org/sites/flosshub.org/files/p39-sudakrishnan.pdf %0 Conference Paper %B Proceedings of the 2006 international workshop on Mining software repositories %D 2006 %T How long did it take to fix bugs? %A Kim, Sunghun %A Whitehead,Jr., E. James %K argouml %K bug fixing %K bugs %K mining challenge %K msr challenge %K postgresql %K quality %K time %X The number of bugs (or fixes) is a common factor used to measure the quality of software and assist bug related analysis. For example, if software files have many bugs, they may be unstable. In comparison, the bug-fix time--the time to fix a bug after the bug was introduced--is neglected. We believe that the bug-fix time is an important factor for bug related analysis, such as measuring software quality. For example, if bugs in a file take a relatively long time to be fixed, the file may have some structural problems that make it difficult to make changes. In this report, we compute the bug-fix time of files in ArgoUML and PostgreSQL by identifying when bugs are introduced and when the bugs are fixed. This report includes bug-fix time statistics such as average bug-fix time, and distributions of bug-fix time. We also list the top 20 bug-fix time files of two projects. %B Proceedings of the 2006 international workshop on Mining software repositories %S MSR '06 %I ACM %C New York, NY, USA %P 173–174 %@ 1-59593-397-2 %U http://doi.acm.org/10.1145/1137983.1138027 %R http://doi.acm.org/10.1145/1137983.1138027 %> https://flosshub.org/sites/flosshub.org/files/173HowLong.pdf %0 Conference Paper %B Proceedings of the 2006 international workshop on Mining software repositories %D 2006 %T Micro pattern evolution %A Kim, Sunghun %A Pan, Kai %A Whitehead,Jr., E. James %K argouml %K bugs %K columba %K design patterns %K evolution %K extraction %K java %K jedit %K source code %X When analyzing the evolution history of a software project, we wish to develop results that generalize across projects. One approach is to analyze design patterns, permitting characteristics of the evolution to be associated with patterns, instead of source code. Traditional design patterns are generally not amenable to reliable automatic extraction from source code, yet automation is crucial for scalable evolution analysis. Instead, we analyze “micro pattern” evolution; patterns whose abstraction level is closer to source code, and designed to be automatically extractable from Java source code or bytecode. We perform micro-pattern evolution analysis on three open source projects, ArgoUML, Columba, and jEdit to identify micro pattern frequencies, common kinds of pattern evolution, and bug-prone patterns. In all analyzed projects, we found that the micro patterns of Java classes do not change often. Common bug- prone pattern evolution kinds are ‘Pool → Pool’, ‘Implementor → NONE’, and ‘Sampler → Sampler’. Among all pattern evolution kinds,‘Box’,‘CompoundBox’, ‘Pool’, ‘CommonState’, and ‘Outline’ micro patterns have high bug rates, but they have low frequencies and a small number of changes. The pattern evolution kinds that are bug-prone are somewhat similar across projects. The bug-prone pattern evolution kinds of two different periods of the same project are almost identical. %B Proceedings of the 2006 international workshop on Mining software repositories %S MSR '06 %I ACM %C New York, NY, USA %P 40–46 %@ 1-59593-397-2 %U http://doi.acm.org/10.1145/1137983.1137995 %R http://doi.acm.org/10.1145/1137983.1137995 %> https://flosshub.org/sites/flosshub.org/files/40MicroPattern.pdf %0 Conference Paper %B Proceedings of the 2006 international workshop on Mining software repositories %D 2006 %T Mining version archives for co-changed lines %A Zimmermann, Thomas %A Kim, Sunghun %A Zeller, Andreas %A Whitehead,Jr., E. James %K change %K change analysis %K change management %K graph %K lines of code %K source code %X Files, classes, or methods have frequently been investigated in recent research on co-change. In this paper, we present a first study at the level of lines. To identify line changes across several versions, we define the annotation graph which captures how lines evolve over time. The annotation graph provides more fine-grained software evolution information such as life cycles of each line and related changes: "Whenever a developer changed line 1 of version.txt she also changed line 25 of Library.java." %B Proceedings of the 2006 international workshop on Mining software repositories %S MSR '06 %I ACM %C New York, NY, USA %P 72–75 %@ 1-59593-397-2 %U http://doi.acm.org/10.1145/1137983.1138001 %R http://doi.acm.org/10.1145/1137983.1138001 %> https://flosshub.org/sites/flosshub.org/files/72MiningVersionArchives.pdf %0 Conference Paper %B Proceedings of the 2005 international workshop on Mining software repositories %D 2005 %T Analysis of signature change patterns %A Kim, Sunghun %A Whitehead,Jr., E. James %A Bevan, Jennifer %K apache %K gcc %K kernel %K linux %K signature change %K signature change patterns %K software evolution %K software evolution path %K soure code %X Software continually changes due to performance improvements, new requirements, bug fixes, and adaptation to a changing operational environment. Common changes include modifications to data definitions, control flow, method/function signatures, and class/file relationships. Signature changes are notable because they require changes at all sites calling the modified function, and hence as a class they have more impact than other change kinds.We performed signature change analysis over software project histories to reveal multiple properties of signature changes, including their kind, frequency, and evolution patterns. These signature properties can be used to alleviate the impact of signature changes. In this paper we introduce a taxonomy of signature change kinds to categorize observed changes. We report multiple properties of signature changes based on an analysis of eight prominent open source projects including the Apache HTTP server, GCC, and Linux 2.5 kernel. %B Proceedings of the 2005 international workshop on Mining software repositories %S MSR '05 %I ACM %C New York, NY, USA %P 1–5 %@ 1-59593-123-6 %U http://doi.acm.org/10.1145/1082983.1083154 %R http://doi.acm.org/10.1145/1082983.1083154 %> https://flosshub.org/sites/flosshub.org/files/64AnalysisOfSignature.pdf