Is It Safe to Uplift This Patch? An Empirical Study on Mozilla Firefox

TL;DR

This study analyzes the risks and characteristics of patch uplift in Mozilla Firefox, revealing factors that lead to regressions and organizational influences on uplift decisions.

Contribution

It provides an empirical analysis of uplifted patches at Mozilla, identifying features associated with regressions and organizational factors affecting uplift decisions.

Findings

Larger patches are more likely to cause faults.

Most faults are due to semantic or memory errors.

Organizational factors influence uplift acceptance.

Abstract

In rapid release development processes, patches that fix critical issues, or implement high-value features are often promoted directly from the development channel to a stabilization channel, potentially skipping one or more stabilization channels. This practice is called patch uplift. Patch uplift is risky, because patches that are rushed through the stabilization phase can end up introducing regressions in the code. This paper examines patch uplift operations at Mozilla, with the aim to identify the characteristics of uplifted patches that introduce regressions. Through statistical and manual analyses, we quantitatively and qualitatively investigate the reasons behind patch uplift decisions and the characteristics of uplifted patches that introduced regressions. Additionally, we interviewed three Mozilla release managers to understand organizational factors that affect patch uplift decisions and outcomes. Results show that most patches are uplifted because of a wrong functionality or a crash. Uplifted patches that lead to faults tend to have larger patch size, and most of the faults are due to semantic or memory errors in the patches. Also, release managers are more inclined to accept patch uplift requests that concern certain specific components, and-or that are submitted by certain specific developers.