The object of our study is the impact of OSes and environ- ments on build results to analyze the phenomenon of “build inflation”, where an excessive number of builds on heteroge- neous combinations of OSes and environments can introduce bias in build results.
For the full study, we measured the agreement (a) for each combination of (round, group) separately (i.e., two raters per comment), and (b) across both groups (i.e., more than two raters per comment).
We select these four publicly available repair techniques that have been evaluated against the Defects4J benchmark and ignore others which either focus on another language [29, 40, 56] or are not publicly available [22, 24].
To make our analysis feasible, we did not distinguish between the 573 different hardware architectures in our data set, but treated them as equal. The analysis of the impact of hardware architecture is left as future work.
To reduce time and (to some degree) simplify our analysis, we filtered out the other OSes and Perl environments, yielding a data set of 62.8 million builds on 10 OSes and 13 environments (Perl 5.8 to 5.21, excluding 5.09) for a period of about 5.5 years between January 2011 to June 2016.
The first phase in the release engineering pipeline is the movement of code changes made by developers in their own development branch across their team’s branch all the way up to the project’s master branch [13].
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
