@proceedings {1750,
	title = {Co-evolution of Infrastructure and Source Code - An Empirical Study},
	year = {2015},
	month = {05/2015},
	abstract = {Infrastructure-as-code automates the process of
configuring and setting up the environment (e.g., servers, VMs
and databases) in which a software system will be tested and/or
deployed, through textual specification files in a language like
Puppet or Chef. Since the environment is instantiated automatically
by the infrastructure languages{\textquoteright} tools, no manual
intervention is necessary apart from maintaining the infrastructure
specification files. The amount of work involved with such
maintenance, as well as the size and complexity of infrastructure
specification files, have not yet been studied empirically. Through
an empirical study of the version control system of 265 OpenStack
projects, we find that infrastructure files are large and churn
frequently, which could indicate a potential of introducing bugs.
Furthermore, we found that the infrastructure code files are
coupled tightly with the other files in a project, especially test files,
which implies that testers often need to change infrastructure
specifications when making changes to the test framework and
tests.},
	keywords = {openstack},
	url = {http://mcis.polymtl.ca/publications/2015/msrjojo.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/msrjojo.pdf},
	author = {Yujuan Jiang and Adams, Bram}
}
@proceedings {1499,
	title = {Will My Patch Make It? And How Fast?: Case Study on the Linux Kernel},
	year = {2013},
	month = {05/2013},
	abstract = {The Linux kernel follows an extremely distributed reviewing and integration process supported by 130 developer mailing lists and a hierarchy of dozens of Git repositories for version control. Since not every patch can make it and of those that do, some patches require a lot more reviewing and integration effort than others, developers, reviewers and integrators need support for estimating which patches are worthwhile to spend effort on and which ones do not stand a chance. This paper cross- links and analyzes eight years of patch reviews from the kernel mailing lists and committed patches from the Git repository to understand which patches are accepted and how long it takes those patches to get to the end user. We found that 33\% of the patches makes it into a Linux release, and that most of them need 3 to 6 months for this. Furthermore, that patches developed by more experienced developers are more easily accepted and faster reviewed and integrated. Additionally, reviewing time is impacted by submission time, the number of affected subsystems by the patch and the number of requested reviewers.},
	author = {Yujuan Jiang and Adams, Bram and Daniel M. German}
}
