@conference {Sudakrishnan:2008:UBF:1370750.1370761,
	title = {Understanding bug fix patterns in verilog},
	booktitle = {Proceedings of the 2008 international working conference on Mining software repositories},
	series = {MSR {\textquoteright}08},
	year = {2008},
	pages = {39{\textendash}42},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {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.},
	keywords = {bug fixing, error classification, hdl, verilog, VHDL},
	isbn = {978-1-60558-024-1},
	doi = {http://doi.acm.org/10.1145/1370750.1370761},
	url = {http://doi.acm.org/10.1145/1370750.1370761},
	attachments = {https://flosshub.org/sites/flosshub.org/files/p39-sudakrishnan.pdf},
	author = {Sudakrishnan, Sangeetha and Madhavan, Janaki and Whitehead,Jr., E. James and Renau, Jose}
}
@conference {Kim:2006:LDT:1137983.1138027,
	title = {How long did it take to fix bugs?},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {173{\textendash}174},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {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.},
	keywords = {argouml, bug fixing, bugs, mining challenge, msr challenge, postgresql, quality, time},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138027},
	url = {http://doi.acm.org/10.1145/1137983.1138027},
	attachments = {https://flosshub.org/sites/flosshub.org/files/173HowLong.pdf},
	author = {Kim, Sunghun and Whitehead,Jr., E. James}
}
@conference {Kim:2006:MPE:1137983.1137995,
	title = {Micro pattern evolution},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {40{\textendash}46},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {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 {\textquotedblleft}micro pattern{\textquotedblright} 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 {\textquoteleft}Pool {\textrightarrow} Pool{\textquoteright}, {\textquoteleft}Implementor {\textrightarrow} NONE{\textquoteright}, and {\textquoteleft}Sampler {\textrightarrow} Sampler{\textquoteright}. Among all pattern evolution	kinds,{\textquoteleft}Box{\textquoteright},{\textquoteleft}CompoundBox{\textquoteright},	{\textquoteleft}Pool{\textquoteright}, {\textquoteleft}CommonState{\textquoteright}, and {\textquoteleft}Outline{\textquoteright} 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.},
	keywords = {argouml, bugs, columba, design patterns, evolution, extraction, java, jedit, source code},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1137995},
	url = {http://doi.acm.org/10.1145/1137983.1137995},
	attachments = {https://flosshub.org/sites/flosshub.org/files/40MicroPattern.pdf},
	author = {Kim, Sunghun and Pan, Kai and Whitehead,Jr., E. James}
}
@conference {Zimmermann:2006:MVA:1137983.1138001,
	title = {Mining version archives for co-changed lines},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {72{\textendash}75},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {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."},
	keywords = {change, change analysis, change management, graph, lines of code, source code},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138001},
	url = {http://doi.acm.org/10.1145/1137983.1138001},
	attachments = {https://flosshub.org/sites/flosshub.org/files/72MiningVersionArchives.pdf},
	author = {Zimmermann, Thomas and Kim, Sunghun and Zeller, Andreas and Whitehead,Jr., E. James}
}
@conference {Kim:2005:ASC:1083142.1083154,
	title = {Analysis of signature change patterns},
	booktitle = {Proceedings of the 2005 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}05},
	year = {2005},
	pages = {1{\textendash}5},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {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.},
	keywords = {apache, gcc, kernel, linux, signature change, signature change patterns, software evolution, software evolution path, soure code},
	isbn = {1-59593-123-6},
	doi = {http://doi.acm.org/10.1145/1082983.1083154},
	url = {http://doi.acm.org/10.1145/1082983.1083154},
	attachments = {https://flosshub.org/sites/flosshub.org/files/64AnalysisOfSignature.pdf},
	author = {Kim, Sunghun and Whitehead,Jr., E. James and Bevan, Jennifer}
}
