@conference {1216,
	title = {Experiences Mining Open Source Release Histories},
	booktitle = {International Conference on Software and Systems Process (ICSSP 2011) },
	year = {2011},
	note = {"First, we selected the projects to initially target, using several criteria to get a broad picture of the open source landscape. Second, we collected the actual data, using a framework of parsers and some manual inspection. Third, we standardized and inserted the data into a database for later use."

"but we plan to eventually cross reference our list of projects with existing open source project information (such as FLOSSmole) to take advantage of the work already done by other researchers."

"For each release, we collected the following data: the project it belonged to, the date the release was published, the type of release, the release label (version number) and the source of the data"

discussion of their difficulties

"We conclude that programmatically creating a release history database from existing open source data is not trivial,"

"We have currently collected 1579 distinct releases from 22 different open source projects"},
	month = {05/2011},
	abstract = {Software releases form a critical part of the life cycle of a software project. Typically, each project produces releases in its own way, using various methods of versioning, archiving, announcing and publishing the release. Understanding the release history of a software project can shed light on the project history, as well as the release process used by that project, and how those processes change. However, many factors make automating the retrieval of release history information difficult, such as the many sources of data, a lack of relevant standards and a disparity of tools used to create releases.

In spite of the large amount of raw data available, no attempt has been made to create a release history database of a large number of projects in the open source ecosystem. This paper presents our experiences, including the tools, techniques and pitfalls, in our early work to create a software release history database which will be of use to future researchers who want to study and model the release engineering process in greater depth.},
	keywords = {doap, flossmole cited, life cycle, release engineering, release history, release management, releases},
	attachments = {https://flosshub.org/sites/flosshub.org/files/icssp11short-p034-tsay.pdf},
	author = {Jason Tsay and Wright, Hyrum and Perry, Dewayne}
}
@conference {D{\textquoteright}Ambros:2006:AER:1137983.1138029,
	title = {Applying the evolution radar to PostgreSQL},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {177{\textendash}178},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	keywords = {cvs, documentation, evolution, evolution radar, logical coupling, makefile, mining challenge, msr challenge, postgresql, re-engineering, refactoring, release history, rhdb, source code, version control, visualization},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138029},
	url = {http://doi.acm.org/10.1145/1137983.1138029},
	attachments = {https://flosshub.org/sites/flosshub.org/files/177ApplyingEvolution.pdf},
	author = {D{\textquoteright}Ambros, Marco and Lanza, Michele}
}
@conference {WeiBgerber:2006:MRA:1137983.1138028,
	title = {Mining refactorings in ARGOUML},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	note = {"To see if refactorings in ARGOUML have an effect on the occurrence of new bugs and on communication between the developers, we relate the refactorings to bug reports in ISSUEZILLA respectively to mails on the developer mailing list. "},
	pages = {175{\textendash}176},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {In this paper we combine the results of our refactoring reconstruc- tion technique with bug, mail and release information to perform process and bug analyses of the ARGOUML CVS archive.},
	keywords = {argouml, bug tracking, bugs, cvs, email, evolution, mining challenge, msr challenge, re-engineering, refactoring, release history},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138028},
	url = {http://doi.acm.org/10.1145/1137983.1138028},
	attachments = {https://flosshub.org/sites/flosshub.org/files/175MiningRefactorings.pdf},
	author = {Wei{\ss}gerber, Peter and Diehl, Stephan and G{\"o}rg, Carsten}
}
@article {2006,
	title = {Opportunities and Challenges Applying Functional Data Analysis to the Study of Open Source Software Evolution},
	journal = {Statistical Science},
	volume = {21},
	number = {2},
	year = {2006},
	note = {"As part of a larger project, data were collected on 105 OSS	projects hosted online at Sourceforge (sf.net)." "...we limited our data collection to projects that use only the Java programming language and were listed in the Internet and System Networking domains." "... only including these projects that use an OSI approved license..." "had to have posted at least one file on the Sourceforge site as of the time of our initial project selection Fall 2002" "Data were collected on the published release history of each project thatmet the screening criteria. Each release of each project was
analyzed to calculate CplXLCoh. The size of each release was measured using a calculation of the number of lines of code (LOC)"},
	pages = {167-178},
	publisher = {Institute of Mathematical Statistics},
	abstract = {This paper explores the application of functional data analysis (FDA) as a means to study the dynamics of software evolution in the open source context. Several challenges in analyzing the data from software projects are discussed, an approach to overcoming those challenges is described, and preliminary results from the analysis of a sample of open source software (OSS) projects are provided. The results demonstrate the utility of FDA for uncovering and categorizing multiple distinct patterns of evolution in the complexity of OSS projects. These results are promising in that they demonstrate some patterns in which the complexity of software decreased as the software grew in size, a particularly novel result. The paper reports preliminary explorations of factors that may be associated with decreasing complexity patterns in these projects. The paper concludes by describing several next steps for this research project as well as some questions for which more sophisticated analytical techniques may be needed.},
	keywords = {complexity, evolution, fda, java, lines of code, loc, release history, scm, size, sourceforge},
	issn = {08834237},
	url = {http://www.jstor.org/stable/27645747},
	author = {Stewart, Katherine J. and Darcy, David P. and Daniel, Sherae L.}
}
@conference {Knab:2006:PDD:1137983.1138012,
	title = {Predicting defect densities in source code files with decision tree learners},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {119{\textendash}125},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {With the advent of open source software repositories the data available for defect prediction in source files increased tremendously. Although traditional statistics turned out to derive reasonable results the sheer amount of data and the problem context of defect prediction demand sophisticated analysis such as provided by current data mining and machine learning techniques.In this work we focus on defect density prediction and present an approach that applies a decision tree learner on evolution data extracted from the Mozilla open source web browser project. The evolution data includes different source code, modification, and defect measures computed from seven recent Mozilla releases. Among the modification measures we also take into account the change coupling, a measure for the number of change-dependencies between source files. The main reason for choosing decision tree learners, instead of for example neural nets, was the goal of finding underlying rules which can be easily interpreted by humans. To find these rules, we set up a number of experiments to test common hypotheses regarding defects in software entities. Our experiments showed, that a simple tree learner can produce good results with various sets of input data.},
	keywords = {change analysis, data mining, decision tree learner, defect density, defect prediction, mozilla, prediction, release history, scm, source code, version control},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138012},
	url = {http://doi.acm.org/10.1145/1137983.1138012},
	attachments = {https://flosshub.org/sites/flosshub.org/files/119Predicting.pdf},
	author = {Knab, Patrick and Pinzger, Martin and Bernstein, Abraham}
}
@conference {Fischer:2005:MED:1083142.1083145,
	title = {Mining evolution data of a product family},
	booktitle = {Proceedings of the 2005 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}05},
	year = {2005},
	pages = {12-16},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Diversification of software assets through changing requirements impose a constant challenge on the developers and maintainers of large software systems. Recent research has addressed the mining for data in software repositories of single products ranging from fine- to coarse grained analyses. But so far, little attention has been payed to mining data about the evolution of product families. In this work, we study the evolution and commonalities of three variants of the BSD (Berkeley Software Distribution), a large open source operating system. The research questions we tackle are concerned with how to generate high level views of the system discovering and indicating evolutionary highlights. To process the large amount of data, we extended our previously developed approach for storing release history information to support the analysis of product families. In a case study we apply our approach on data from three different code repositories representing about 8.5GB of data and 10 years of active development.},
	keywords = {bsd, change analysis, change history, cvs, evolution, freebsd, netbsd, openbsd, release history, source code, text mining},
	isbn = {1-59593-123-6},
	doi = {http://doi.acm.org/10.1145/1082983.1083145},
	url = {http://doi.acm.org/10.1145/1082983.1083145},
	attachments = {https://flosshub.org/sites/flosshub.org/files/12MiningEvolution.pdf},
	author = {Fischer, Michael and Oberleitner, Johann and Ratzinger, Jacek and Gall, Harald}
}
@article {1113,
	title = {Release criteria for the Linux kernel},
	journal = {First Monday},
	volume = {9},
	number = {4},
	year = {2004},
	note = {"The first was to examine the change logs [10, 11, 12] that are submitted with the public release of a version of the kernel on www.kernel.org [1]. Observations were made on the release nomenclature used in both the 2.4.x series and the 2.5.x (which later became the 2.6.x series). The number of patches incorporated into each release and the elapsed time between releases was recorded. The second approach was to review the Linux kernel mailing list [2] for any evidence of criteria for performing a particular release including any metrics used, tests carried out or bug databases referenced."},
	month = {2004},
	abstract = {Before software is released to its users, software developers will ensure that the software has met specified functional and technical requirements and that it is as free from bugs as possible. Users should be able to have a high degree of confidence that the software will perform as specified and without fault. With open source development practices such as those employed on the Linux kernel project, there are no detailed specifications and little formal testing processes. The questions, then, are what criteria, if any, are used in determining the suitability for release of a particular version of this software, and do users have any degree of confidence in the quality of that release of software? These questions were examined in this study using information from the Linux Kernel Mailing List (LKML), the primary forum for discussion of development issues of the Linux kernel, and change logs submitted with version releases of the Linux kernel. It was determined that very little planning is employed in determining the release of a particular version of the software and that a version of the software is essentially a collection of source patches released at regular intervals with some stabilisation of the code base before each release. Very little attempt is made to verify that the code is bug free, and consequently, the code released is of a largely unknown level of quality. End users are left to decide for themselves the suitability and robustness of a particular version of the software.},
	keywords = {bugs, change log, linux, linux kernel, log files, mailing list, patches, quality, release history},
	url = {http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/1136/1056},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Glance.pdf},
	author = {Glance, D.G.}
}
@conference {1153,
	title = {Characterizing the OSS process},
	booktitle = {Proceedings of the 2nd ICSE Workshop on Open Source},
	year = {2002},
	note = {"We have considered two well-known Open Source portals (FreshMeat [1] and SourceForge [2] )."
"Using pseudo-random sampling we have selected a sample of 400 projects (mostly from FreshMeat). Each project is described by several variables (programming language, type of license, size of source code, type of documentation available and others). By indirect means (analysis of the Changelog file, or CVS) it is also possible to compute the number of people working on the project, and the number of external contributors. From FreshMeat we get both a vitality index, that considers the number of releases per time period, and a popularity index, which is a first measure of the interest of users to the project (project URL hits, mixed with subscriptions to it)."},
	abstract = {The Open Source model of software development has gained the attention of both the business, the practitioners{\textquoteright} and the research communities. The Open Source process has been described by the seminal paper by Eric Raymond [4] and [5]. However, sound empirical studies are still very limited [3], [6].
Our goal is to investigate the OS process by empirical means, to analyze, characterize it, and possibly model it with quantitative models. It should be noted that the Open Source process provides open process and product data, and therefore is a rare opportunity for empirical research.
Our initial research focus is on the characterization of the process, starting from the evolution of OS projects. In traditional projects, a significant number of releases in a short time is usually considered an instability factor [7] and [8], while in the OSS community, it is an evidence of vitality, shows the commitment of the authors and the power of attraction of other programmers [9]. Is it possible to characterize the vitality of projects? And, can vitality be traced to some other characteristics of a project?},
	keywords = {bugs, change log, classification, cvs, downloads, freshmeat, metadata, patches, popularity, project success, release history, sourceforge, vitality},
	attachments = {https://flosshub.org/sites/flosshub.org/files/CapiluppiLagoMorisio.pdf},
	author = {Capiluppi, Andrea and Patricia Lago and Maurizio Morisio}
}
