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].
we present an overview of the defect categorization approaches in the literature.
Figure 1 gives an overview of the multiple knapsack problem
Fig. 1 depicts a path diagram showing a direct relationship between an independent variable (IV, an OO metric) and a dependent variable (DV, number of faults).
Given an independent variable X and a dependent variable Y , the effect of X on Y may be transmitted through a third intervening (mediating) variable M.
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].