Is It Safe to Uplift This Patch? An Empirical Study on Mozilla Firefox
This work addresses the risk of introducing regressions in rapid release processes for software developers and release managers, but it is incremental as it builds on existing studies of patch quality and uplift practices.
The paper studied patch uplift operations in Mozilla Firefox to identify characteristics of uplifted patches that cause regressions, finding that most uplifted patches address wrong functionality or crashes, and those leading to faults tend to be larger and involve semantic or memory errors.
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.