@proceedings {1752, title = {Why Power Laws? An Explanation from Fine-Grained Code Changes}, year = {2015}, note = {"The data used in this section come from four open source Java projects. We used CVSANALY to collect data from their Git repositories."}, abstract = {Throughout the years, empirical studies have found power law distributions in various measures across many software systems. However, surprisingly little is known about how they are produced. What causes these power law distributions? We offer an explanation from the perspective of fine-grained code changes. A model based on preferential attachment and selforganized criticality is proposed to simulate software evolution. The experiment shows that the simulation is able to render power law distributions out of fine-grained code changes, suggesting preferential attachment and self-organized criticality are the underlying mechanism causing the power law distributions in software systems.}, keywords = {Apache Maven, cvsanaly, eclipse, git, Google Guice, java, jedit, open source}, url = {https://users.soe.ucsc.edu/~linzhp/msr2015.pdf}, attachments = {https://flosshub.org/sites/flosshub.org/files/msr2015.pdf}, author = {Zhongpeng Lin and Jim Whitehead} } @conference {1000, title = {Mining Workspace Updates in CVS}, booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)}, year = {2007}, pages = {11 - 11}, publisher = {IEEE}, organization = {IEEE}, address = {Minneapolis, MN, USA}, abstract = {The version control archive CVS records not only all changes in a project but also activity data such as when developers create or update their workspaces. Furthermore, CVS records when it has to integrate changes because of parallel development. In this paper, we analyze the CVS activity data of four large open-source projects GCC, JBOSS, JEDIT, and PYTHON to investigate parallel development: What is the degree of parallel development? How frequently do conflicts occur during updates and how are they resolved? How do we identify changes that contain integrations?}, keywords = {change management, cvs, developers, gcc, jboss, jedit, python, workspaces}, isbn = {0-7695-2950-X}, doi = {10.1109/MSR.2007.22}, attachments = {https://flosshub.org/sites/flosshub.org/files/28300011.pdf}, author = {Zimmermann, Thomas} } @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 {1002, title = {Studying Versioning Information to Understand Inheritance Hierarchy Changes}, booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)}, year = {2007}, pages = {16 - 16}, publisher = {IEEE}, organization = {IEEE}, address = {Minneapolis, MN, USA}, abstract = {With the widespread adoption of object-oriented programming, changing the inheritance hierarchy became an inherent part of today{\textquoteright}s software maintenance activities. Unfortunately, little is known about the "state-of-the-practice" with respect to changing an application{\textquoteright}s inheritance hierarchy, and consequently we do not know how the change process can be improved. In this paper, we report on a study of the hierarchy changes stored in a versioning system to explore the answers to three research questions: (1) why are hierarchy changes made? (2) what kind of hierarchy changes are made? (3) what is the impact of these changes? Based on the results of this study, we formulate 7 hypotheses which should be investigated further to make conclusive interpretations on how hierarchy changes fit in the actual change process.}, keywords = {argouml, change management, inheritance, jedit}, isbn = {0-7695-2950-X}, doi = {10.1109/MSR.2007.30}, attachments = {https://flosshub.org/sites/flosshub.org/files/28300016.pdf}, author = {Rysselberghe, Filip Van and Demeyer, Serge} } @conference {WeiBgerber:2006:RLE:1137983.1138011, title = {Are refactorings less error-prone than other changes?}, booktitle = {Proceedings of the 2006 international workshop on Mining software repositories}, series = {MSR {\textquoteright}06}, year = {2006}, pages = {112{\textendash}118}, publisher = {ACM}, organization = {ACM}, address = {New York, NY, USA}, abstract = {Refactorings are program transformations which should preserve the program behavior. Consequently, we expect that during phases when there are mostly refactorings in the change history of a system, only few new bugs are introduced. For our case study we analyzed the version histories of several open source systems and reconstructed the refactorings performed. Furthermore, we obtained bug reports from various sources depending on the system. Based on this data we identify phases when the above hypothesis holds and those when it doesn{\textquoteright}t.}, keywords = {argouml, bug reports, bugs, change history, jedit, junit, re-engineering, refactoring, reverse engineering, software evolution, version control}, isbn = {1-59593-397-2}, doi = {http://doi.acm.org/10.1145/1137983.1138011}, url = {http://doi.acm.org/10.1145/1137983.1138011}, attachments = {https://flosshub.org/sites/flosshub.org/files/112AreRefactorings.pdf}, author = {Wei{\ss}gerber, Peter and Diehl, Stephan} } @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 {Gorg:2005:EDR:1083142.1083148, title = {Error detection by refactoring reconstruction}, booktitle = {Proceedings of the 2005 international workshop on Mining software repositories}, series = {MSR {\textquoteright}05}, year = {2005}, pages = {29-33}, publisher = {ACM}, organization = {ACM}, address = {New York, NY, USA}, abstract = {In many cases it is not sufficient to perform a refactoring only at one location of a software project. For example, refactorings may have to be performed consistently to several classes in the inheritance hierarchy, e.g. subclasses or implementing classes, to preserve equal behavior.In this paper we show how to detect incomplete refactorings - which can cause long standing bugs because some of them do not cause compiler errors - by analyzing software archives. To this end we reconstruct the class inheritance hierarchies, as well as refactorings on the level of methods. Then, we relate these refactorings to the corresponding hierarchy in order to find missing refactorings and thus, errors and inconsistencies that have been introduced in a software project at some point of the history.Finally. we demonstrate our approach by case studies on two open source projects.}, keywords = {bugs, class, inheritance, jedit, refactoring, tomcat}, isbn = {1-59593-123-6}, doi = {http://doi.acm.org/10.1145/1082983.1083148}, url = {http://doi.acm.org/10.1145/1082983.1083148}, attachments = {https://flosshub.org/sites/flosshub.org/files/29ErrorDetection.pdf}, author = {G{\"o}rg, Carsten and Wei{\ss}gerber, Peter} }