The Secret Life of Patches: A Firefox Case Study

Abstract

Abstract-The goal of the code review process is to assess the quality of source code modifications (submitted as patches) before they are committed to a project's version control repository. This process is particularly important in open source projects to ensure the quality of contributions submitted by the community; however, the review process can promote or discourage these contributions. In this paper, we study the patch lifecycle of the Mozilla Firefox project. The model of a patch lifecycle was extracted from both the qualitative evidence of the individual processes (interviews and discussions with developers), and the quantitative assessment of the Mozilla process and practice. We contrast the lifecycle of a patch in preand post-rapid release development. A quantitative comparison showed that while the patch lifecycle remains mostly unchanged after switching to rapid release, the patches submitted by casual contributors are disproportionately more likely to be abandoned compared to core contributors. This suggests that patches from casual developers should receive extra care to both ensure quality and encourage future community contributions.

Work practices and challenges in pull-based development

“…Contributions that are small and isolated are easier for integrators to process. In previous work [51,3,25,27], the size of the change was one of the most important factors related to acceptance. This is because the impact of the change is more easily evaluated, especially if the change does not cross logical functionality or design boundaries.…”

“…Rigby and Storey examined the peer review process in OSS mailing lists and found that developers filter emails to reduce evaluation load, prioritize using progressive detail within emails containing patches, and delegate by appending names to the patch email recipients [41]. Baysal et al [3] examined contribution evaluation over the bug tracking database and found that contributions from casual contributors received preferential treatment, which they attribute to the size of the contributions (i.e., new contributors submit smaller contributions).…”

“…In total, 1,000,000 collaborative GitHub projects (i.e., 45% of all collaborative projects) used at least one pull request during their lifetime. As opposed to more classic ways of contributing (e.g., change sets sent to development mailing lists [4] to issue tracking systems [3] or through direct access to the version control system [17]), in the pull-based model, contributors fork (i.e., locally duplicate) the main repository of the project they want to contribute to, make their changes independently, then create a pull request (PR) to ask that their changes be merged into the main repository. Then the members of the project's core team (the integrators) are responsible for evaluating the quality of the contributions, proposing corrections, engaging in discussion with the contributors, and eventually merging or rejecting the changes.…”

Effective assignment and assistance to software developers and reviewers

“…Bacchelli et al [13] conducted an empirical study across diverse teams at Microsoft to empirically explore the motivations, challenges and outcome of toolbased code reviews. Baysal et al [18] studied the patch lifecycle of the Mozilla Firefox project.…”

“…Recently, a number of empirical studies about various facets of the modern code review process have been reported in the literature [69,82,17,103,49,18,81,83,84]. Deeply inspired by these efforts, we focus our work on the critical topic of finding the human reviewers who are most likely to contribute in peer reviewing source code changes.…”