@conference {972, title = {Extracting structural information from bug reports}, booktitle = {Proceedings of the 2008 international workshop on Mining software repositories - MSR {\textquoteright}08}, year = {2008}, month = {05/2008}, pages = {27-30}, publisher = {ACM Press}, organization = {ACM Press}, address = {New York, New York, USA}, abstract = {In software engineering experiments, the description of bug reports is typically treated as natural language text, although it often contains stack traces, source code, and patches. Neglecting such structural elements is a loss of valuable information; structure usually leads to a better performance of machine learning approaches. In this paper, we present a tool called infoZilla that detects structural elements from bug reports with near perfect accuracy and allows us to extract them. We anticipate that infoZilla can be used to leverage data from bug reports at a different granularity level that can facilitate interesting research in the future.}, keywords = {bug reports, eclipse, enumerations, infozilla, natural language, patches, source code, stack trace}, isbn = {9781605580241}, doi = {10.1145/1370750.1370757}, attachments = {https://flosshub.org/sites/flosshub.org/files/p27-bettenburg.pdf}, author = {Premraj, Rahul and Zimmermann, Thomas and Kim, Sunghun and Bettenburg, Nicolas} } @conference {1012, title = {Prioritizing Warning Categories by Analyzing Software History}, booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)}, year = {2007}, pages = {27 - 27}, publisher = {IEEE}, organization = {IEEE}, address = {Minneapolis, MN, USA}, abstract = {Automatic bug finding tools tend to have high false positive rates: most warnings do not indicate real bugs. Usually bug finding tools prioritize each warning category. For example, the priority of "overflow" is 1 and the priority of "jumbled incremental" is 3, but the tools{\textquoteright} prioritization is not very effective. In this paper, we prioritize warning categories by analyzing the software change history. The underlying intuition is that if warnings from a category are resolved quickly by developers, the warnings in the category are important. Experiments with three bug finding tools (FindBugs, JLint, and PMD) and two open source projects (Columba and jEdit) indicate that different warning categories have very different lifetimes. Based on that observation, we propose a preliminary algorithm for warning category prioritizing.}, keywords = {bug fixing, change history, columba, findbugs, jedit, jlint, kenyon, pmd, warning}, isbn = {0-7695-2950-X}, doi = {10.1109/MSR.2007.26}, attachments = {https://flosshub.org/sites/flosshub.org/files/28300027.pdf}, author = {Kim, Sunghun and Ernst, Michael D.} } @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} }