How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Three Open-Source Ecosystems Ahmed Belhouchette # ENSI, Manouba University, Tunisia
Moataz Chouchen # Concordia University, Montreal, QC, Canada
Marouene Chaieb # ENSI, Manouba University, Tunisia LARODEC Laboratory, ISG-Tunis, Tunis University, Tunisia
Mohammad Hamdaqa # Polytechnique Montréal, Montreal, QC, Canada
Abdelwahab Hamou-Lhadj # Concordia University, Montreal, QC, Canada
arXiv:2607.20189v1 [cs.SE] 22 Jul 2026
Abstract Background. Developers increasingly coordinate dependent review workflows by submitting sequences of related changes rather than monolithic ones. In Gerrit, these dependencies form relation chains: structured review units that link changes together. As chains become more common, they shape review activities through synchronization overhead, CI amplification, and merge-ordering constraints. Aim. We investigate how developers adopt relation chains and how these dependency structures influence review dynamics and outcomes. Method. We analyze 29,580 relation chains from 15 repositories across three Gerrit ecosystems (OpenStack, Wikimedia, ONAP), comprising 401,256 changes, using Mann–Kendall trend tests, Mann–Whitney with Cliff’s δ for chain-vs-solo comparison, and Spearman correlations for base– descendant dependency. Results. Chain prevalence ranges from 5% to 49% across projects, increasing in 14 of 15. Chain changes take a median of 2.6× longer to merge than size-matched solo changes, with the gap widening for very large changes. Review effort propagates through dependency-linked review workflows: basechange review activity co-varies with descendant review activity (ρ = 0.43–0.61 in 14–15/15 projects), and 33.5% of chain members undergo structural evolution during review. Conclusions. Relation chains operate as durable, ecosystem-shaped coordination units with internal structure that change-centric analyses cannot capture. Future review analytics, reviewer-assignment systems, and AI-assisted review tools should reason over chains rather than isolated changes. 2012 ACM Subject Classification Software and its engineering → Software configuration management and version control systems; Software and its engineering → Collaboration in software development; Software and its engineering → Software verification and validation Keywords and phrases Code review, relation chains, stacked changes, dependent patches, empirical software engineering, Gerrit Digital Object Identifier 10.4230/LIPIcs...
1
Introduction
Modern Code Review (MCR) is used to detect defects, discuss design decisions, transfer knowledge, and enforce coding conventions [6, 34, 29, 24, 26]. Large engineering tasks such as refactorings, migrations, and multi-component features are increasingly decomposed into © Ahmed Belhouchette, Moataz Chouchen, Marouene Chaieb, Mohammad Hamdaqa, and Abdelwahab Hamou-Lhadj ; licensed under Creative Commons License CC-BY 4.0 Leibniz International Proceedings in Informatics Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl Publishing, Germany
XX:2
How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Th
sequences of dependent changes submitted as stacked changes. In Gerrit, these structures are represented as relation chains, a higher-level coordination abstraction in modern code-review workflows; similar abstractions exist in Phabricator, Graphite, GitHub, and ghstack [32, 20, 19, 30]. Following the Gerrit documentation [18], we use the term relation chain to denote a dependency-linked review structure in which multiple changes evolve simultaneously and the state of one review directly influences the validation, synchronization, and mergeability of dependent reviews. In this paper, relation chains refer specifically to Gerrit parentSHA dependency structures reconstructed from patchset-level parent relationships; while similar workflows exist in GitHub stacked pull requests, Phabricator, and ghstack, our operationalization and findings are specific to Gerrit-based review ecosystems. Relation chains let reviewers reason about large engineering efforts as coordinated structures rather than isolated changes. Figure 1 shows an OpenStack Neutron example: a pylint migration1 decomposed into descendants addressing different warning categories. The same dependency that enables this coordination can also become a source of friction: updates to one chain member can cascade across descendants through forced rebasing, repeated CI validation, and delayed merge propagation. On ONAP oom change 1001142 , a reviewer warned the author that “as parent is abandoned, we cannot merge. . . please rebase on master,” surfacing parent abandonment, merge blocking, and forced rebasing as everyday chain-coordination costs. Understanding how such dependency structures influence review processes matters for review analytics, prioritization, and tooling [39]. #883464 Update pylint version #883605 Fix W warnings
#883606 Fix R warnings
#883608 Fix C warnings
#890244 Fix W missing-timeout
(a) Gerrit’s Relation Chain panel (b) Relation chain dependency graph. Figure 1 A branching relation chain in OpenStack Neutron (change #8834643 ). (a) Gerrit’s flat Relation Chain panel. (b) The same chain reconstructed from patchset-level parent SHAs: blue is the base, green is a descendant. All five members merged.
Despite their growing adoption, prior research has overlooked relation chains as firstclass review artifacts. Existing work captures only fragments: studies of cross-component dependencies [3] model pairwise relationships between repositories rather than the chain that links a sequence of changes within a single review; Depends-On/Needed-By annotation analyses [2] require the dependency to be declared in the commit message, missing chains created implicitly through parent-SHA links; and patch-linkage research [23, 44, 43] traces references between review discussions but not the structural dependency graph that determines merge order. Properties that emerge only when a change is read together with its in-review parents and children (friction propagation from base to descendant, mid-review restructuring of the dependency graph, position-dependent review effort) fall outside what existing methods
1 2
https://review.opendev.org/c/openstack/neutron/+/883464 https://gerrit.onap.org/r/c/oom/+/100114
A. Belhouchette, M. Chouchen, M. Chaieb, M. Hamdaqa, and A. Hamou-Lhadj
can observe. These workflow effects remain largely invisible when reviews are analyzed as isolated artifacts. The literature has no empirical characterisation of relation chains as the unit through which developers coordinate dependent review work at scale. To address this gap, we present an empirical characterisation of relation chains as first-class review artifacts. We analyze 401,256 reviewed changes and 29,580 chains across three Gerrit ecosystems (OpenStack, Wikimedia, ONAP), selected to span different development cultures, CI-gating regimes, and community sizes. The study combines three lenses: temporal-trend analysis of chain adoption, stratified comparison of chain members against size-matched solo changes, and dependency-aware correlation analysis between base changes and their descendants. Together they let us characterise chains both as a structural feature of the review graph and as a coordination mechanism whose dynamics shape review outcomes that change-level studies cannot observe. Because our analyses are observational, we interpret the reported effects as associations rather than causal consequences of chain membership. Our results converge on a single characterisation: relation chains are durable, ecosystemshaped, internally-structured coordination units whose review dynamics differ from those of isolated changes. Each of the four findings below contributes evidence along one of these dimensions. First, chains are prevalent and growing: prevalence ranges from 5% to 49% and increases in 10 of 15 projects, so dependent-change workflows are not a niche pattern. Second, chains carry review costs not visible at the change level: members take a median of 2.6× longer to merge than size-matched solo changes, with overhead concentrating in very large changes (Cliff’s δ = 0.49), and CI activity is amplified five- to twenty-fold under strict gating. Third, chains have internal structure that shapes review outcomes: middle-of-chain members absorb the highest review effort, and base-change review activity co-varies with descendant activity (ρ = 0.43–0.61 in 14–15 of 15 projects), a regularity we call the foundation effect. Fourth, chains are not static: 33.5% of members undergo a structural change in their parent SHA before merging, and chains can persist across multi-year intermittent timespans, with the longest merge gap reaching 2.85 years on a chain in OpenStack Neutron. These results call into question the default assumption underlying current review tooling, which processes each change independently [40, 31, 25], and motivate chain-aware review analytics, reviewerassignment systems that prioritise members whose merge unblocks the largest downstream subgraph, and AI-assisted review agents that condition on chain position and base-change review state.
2
Background: Modern Code Review, Gerrit, and Relation Chains
Modern Code Review (MCR) is a tool-supported form of peer review used in industrial and open-source development [6, 34, 26], supporting defect detection, design discussion, knowledge transfer, and coding-convention enforcement [29, 24, 8]. Smaller, focused changes are easier to review and more likely to be accepted [45, 33]; larger engineering tasks therefore motivate developers to split work across related changes. Gerrit is a web-based code review platform used by projects such as OpenStack, Android, Chromium, Wikimedia, and ONAP [17, 39]. Each review request is a change identified by a Change-Id and refined through successive patchsets. When a developer uploads a change whose parent commit corresponds to another change still under review, Gerrit links them as a parent–child dependency; a sequence of such linked changes forms a relation chain [18]. Relation chains let developers continue dependent work without waiting for earlier changes to merge. The same workflow appears in Phabricator [32], Graphite [20], Meta’s ghstack [30], and GitHub’s native stacked PRs [19]; earlier work on Linux kernel patch series [35] shows
XX:3
XX:4
How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Th
dependent review workflows predate modern platforms. Figure 2 illustrates a typical workflow. Throughout this paper, base, middle, and top denote the first, intermediate, and last members of a chain, and solo denotes a change with no in-review parent or child. parent SHA = C1
Developer
Reviewers
Change 1 (base)
Review C1 (+patchsets)
no wait
wait
C1 merged
main branch
parent SHA = C2
Change 2 built on C1
no wait
Review C2 (+patchsets)
then
Change 3 built on C2
wait
C2 merged
Review C3 (+patchsets)
then
C3 merged time
The developer keeps building on top. Reviews proceed in parallel, but merges to main must happen bottom-up.
Figure 2 Working with a relation chain in Gerrit. The developer builds C2 on C1 and C3 on C2 without waiting. Reviews proceed in parallel; merges into the main branch are bottom-up.
3
Related Work
We position our study with respect to three lines of work: (i) empirical studies of modern code review that examine review outcomes at the change level, (ii) reviewer recommendation and review automation systems that consume change-level features, and (iii) change decomposition and dependent-review research that touches on multi-change workflows. For each, we summarise what the line has shown and clarify how our chain-level focus differs.
3.1
Empirical Studies in Modern Code Review
Empirical work has examined MCR at the change level, characterizing factors that shape review latency and outcomes [8, 24, 47, 48] and the role of reviewer expectations and practice [6, 34, 26]. McIntosh et al. [29] showed that low review coverage and participation correlate with post-release defects; follow-up work examined review participation across Android, Qt, and OpenStack [39] and code ownership in MCR [38]. Change size is a recurring predictor [45, 33], and CI plays a parallel role: prior studies analyzed its effect on review duration [9], the cost of repeated builds in OpenStack [27], and bot activity in review [46]. Key difference from our work. Prior empirical MCR studies treat each review as an independent unit. We shift the focus to chain-level coordination (review effort, conversation, and dependency-graph evolution when a change belongs to a relation chain) and identify intra-chain structural factors such as chain position, base-change activity, and structural evolution that change-level analyses cannot observe.
3.2
Reviewer Recommendation and Review Automation
Two adjacent lines of work aim to reduce review effort through tooling. Reviewer recommendation systems suggest reviewers based on file-location history [40] or expertise and workload [31], while pull-request decision factors have been studied on GitHub [48]. LLMbased review automation extends this with pre-trained models that generate or refine review
A. Belhouchette, M. Chouchen, M. Chaieb, M. Hamdaqa, and A. Hamou-Lhadj
comments [25, 41, 21]. Related work has built predictive models on change-level features for merged-vs-abandoned classification [11], completion-time prediction [12], and effort-aware prioritization [10]. Key difference from our work. Existing tools operate on individual changes and do not consume chain-level signals such as chain position, base-change review state, or evolving dependency graphs. Our study shows the importance of accounting for this dependency context when reasoning about review outcomes, providing a concrete extension point for chain-aware tooling.
3.3
Change Decomposition and Dependent Reviews
The benefits of smaller review units create a tension: focused changes improve reviewability, but real engineering tasks are often too large for a single review. Prior work has studied change decomposition: Barnett et al. [7] proposed automated decomposition for tangled changesets at Microsoft, and Di Biase et al. [15] showed decomposed changes reduce falsepositive review comments and improve review quality. Related work on dependencies: Arabat and Sayagh [3] found inter-component dependencies persist in microservice systems; Arabat et al. [2] examined explicit Depends-On/Needed-By annotations in OpenStack; patch linkages [23, 44, 43] trace references between review discussions; and change coupling [16, 49] mines version histories for co-evolving files. Key difference from our work. Decomposition research treats decomposition as a property of individual changes; dependency research models dependencies as pairwise or textual. Relation chains are the mechanism by which developers implement decomposition in practice, introducing structural dynamics (base-change effects on descendants, merge-ordering constraints, dependency-graph evolution) that change-level studies cannot observe.
4
Study Design
Figure 3 shows an illustration of our study.
4.1
Research Questions
We organize our study around three research questions that progressively examine relation chains as code-review artifacts: how developers adopt them across projects and over time, how chain membership relates to review outcomes compared to isolated changes, and which intra-chain structural factors shape those outcomes. RQ1. [Chain Usage] What characterizes the usage of relation chains across projects and ecosystems? RQ2. [Chain vs. Solo Outcomes] How do relation chains reshape review coordination, validation workload, and review latency compared to isolated changes? RQ3. [Intra-chain Structural Factors] What structural factors within a chain shape its review outcomes? RQ1 establishes how often, how deeply, and over what time horizon developers use chains. The basic shape of chain usage (prevalence, depth, temporal stability) determines whether chain-level analysis is broadly relevant or confined to a narrow slice within a few projects. RQ2 examines whether reviews that belong to a relation chain differ systematically from isolated reviews in terms of review duration, rebasing activity, discussion, and CI workload. We compare chain and solo changes within the same size categories and inspect whether similar patterns appear across projects. If chain-associated reviews consistently differ from
XX:5
XX:6
How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Th
Figure 3 Study methodology overview.
isolated reviews, then chain-level signals may be useful for future review analytics and tooling. Because the study is observational, we interpret the results as recurring associations rather than direct causal effects of chaining. RQ3 then examines which intra-chain features drive the differences identified in RQ2 (chain position, base-change activity, structural evolution), turning the chain from a binary attribute into a set of fine-grained signals that downstream review-support tools (recommendation systems, dashboards, CI schedulers) could consume. Limitations are discussed in Section 7.
4.2
Phase I: Data Extraction
We selected three Gerrit ecosystems (OpenStack, Wikimedia, ONAP) as representative large ecosystems where coordination across dependent changes is needed, and where prior MCR research has established the platform as a reliable empirical setting [29, 23, 39, 8]. The three differ on dimensions likely to interact with chain behaviour: review culture, language and domain, and CI-gating strictness, letting us separate effects that are general properties of chains from those tied to a specific development context. All three use the same review platform with the same chain-detection mechanism (patchset-level parent-SHA links), so cross-ecosystem comparisons rest on a uniform data model. Within each ecosystem, we required publicly accessible review history, at least 1,000 completed changes, and active development spanning multiple years, following prior MCR conventions [29, 23, 3]. Table 1 summarizes the corpus. For each project, we queried the Gerrit REST API in five passes covering change metadata, patchset revisions with parent SHAs, file-level diffs, review messages (distinguishing humans from CI bots), and review labels.
A. Belhouchette, M. Chouchen, M. Chaieb, M. Hamdaqa, and A. Hamou-Lhadj
Table 1 Overview of the studied Gerrit corpus across the OpenStack, Wikimedia, and ONAP ecosystems. Per-project counts of total changes, merged and abandoned outcomes, and reconstructed relation chains. Ecosystem Project Changes Merged Aband. Chains OpenStack nova 42,781 31,145 11,636 3,682 neutron 29,151 22,430 6,603 2,015 cinder 18,797 13,793 4,094 1,104 horizon 13,654 10,503 3,058 406 heat 12,446 10,047 2,299 498 Wikimedia mw/core 84,626 72,884 10,276 10,036 ext/Wikibase 28,839 25,692 2,972 3,662 ext/VE 17,194 16,080 986 1,291 ext/MF 15,365 13,830 1,501 1,341 ops/puppet† 118,257 110,366 7,891 3,012 ONAP so 5,208 4,439 699 680 sdc 4,728 4,157 543 846 oom 5,743 4,812 904 588 cps 2,524 2,264 243 184 ccsdk/cds 1,943 1,809 131 235 Total 401,256 29,580 †
ops/puppet’s chain count includes one auto-generated chain of depth 59,945 from its config-as-code workflow; we exclude it from aggregate statistics.
4.3
Phase II: Chain Detection and Metric Computation
A relation chain is a set of Gerrit changes linked by parent–child dependencies at the patchset level. Every patchset is a full git commit with a parent SHA; Gerrit detects a chain link whenever a patchset’s parent SHA matches the latest revision SHA of another in-review change in the same project. Because each change has its own evolving patchset sequence, the parent SHA can change across patchsets, the mechanism by which chains restructure during review (Section 5.3). For chain detection (step 2), we follow Gerrit’s convention and link changes by the parent SHA of each change’s latest patchset. A change with no in-review parent and no in-review children is classified as solo. We label each chain member by position: the base has no in-review parent, the top has no in-review descendant, and middle members are neither. In a chain of n ≥ 3, exactly one base, one top, and n − 2 middle members exist; branching chains produce one top per branch. Solo is a fourth label for changes outside any chain. For each change we compute six per-change metrics (step 3). #Revisions is the number of distinct patchset revisions, from the Gerrit revisions endpoint [29, 23, 38]. #Rebases is the subset of patchsets whose kind is NO_CHANGE or TRIVIAL_REBASE, isolating dependency-driven rebases from substantive revisions. Review duration (hours) is the time from first patchset upload to final state, computed across merged and abandoned changes to avoid survivorship bias [8, 47]. Discussion messages is the count of top-level human review messages, excluding accounts on a per-project bot allowlist (top-50 commenters, CI usernames such as zuul, jenkins) [29, 46]. Inline comments is the count of human-authored code-anchored comments, filtered with the same allowlist. CI/CD jobs is the count of verification messages from accounts in the bot allowlist [27, 9]. To account for change size as a confound, changes are bucketed by Gerrit size category (XS: ≤ 9 lines; S: 10–29; M: 30–99; L: 100–999; XL: ≥ 1000) [29, 23]. At the chain level (step 4) we compute four per-chain metrics. Chain depth is the number of members (≥ 2). Submission gap and merge gap are computed for each consecutive pair (ci , ci+1 ) as the time between uploads and between merges. For each chain with at least two merged members, we compute the base-change and descendant-mean values of each per-change metric, supporting correlation analyses. For chain-evolution analysis we compare each member’s parent SHA at Patchset 1 against its parent SHA at the final patchset, classifying any non-trivial-rebase change as a structural evolution event.
XX:7
XX:8
How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Th
4.4
Phase III: Analysis
We use non-parametric tests throughout, chosen for robustness to the right-skewed distributions of code-review metrics [4, 5]. All tests are two-sided (null hypothesis: both samples come from the same population). For RQ1’s temporal trend (step 5), monthly prevalence series violate the independence assumption of standard correlation tests, as consecutive months share contributors, release cadences, and backlogs. We assess monotonic trends with the Mann–Kendall test [14] (robust to autocorrelation) and report Sen’s slope [37] in percentage points per year (pp/yr). Both are established in SE temporal studies [42, 22]. H0 : no monotonic trend; H1 : increasing or decreasing trend. For chain-vs-solo two-sample comparisons (RQ2, step 6), we report Mann–Whitney U [28, 14] and Cliff’s δ [13] with thresholds from Romano et al. [36]: |δ| < 0.147 negligible, < 0.33 small, < 0.474 medium, ≥ 0.474 large. H0 : a random chain member and a random solo change have equal probability of being larger; H1 : one is stochastically greater. Given the large sample sizes, significance alone can be misleading; we therefore interpret Cliff’s δ as the primary estimate of practical magnitude and focus on directional consistency across projects and ecosystems. For per-chain base-vs-descendant correlations (RQ3, step 7), we report Spearman’s ρ with two-sided p-values [14], which captures monotonic association without assuming linearity or normality. H0 : base-change and descendant-mean metrics are independent in rank; H1 : they are monotonically associated. Significance markers: *** p < 0.001, ** p < 0.01, * p < 0.05, ns otherwise. No multiple-comparison correction is applied; each project is an independent observational unit, and we interpret the sign and magnitude of each effect individually.
5
Results
5.1
RQ1: Prevalence and Structure
Table 2 summarizes per-project chain-prevalence trends; Figure 4 illustrates two contrasting exemplars. Table 3 reports per-project chain-depth statistics, and Figure 5 shows monthly mean chain depth per project. Table 2 Per-project chain-prevalence trends (Mann–Kendall test on monthly prevalence series). Chained % is the proportion of project changes that belong to a relation chain. Sen’s slope reports the trend magnitude in percentage points per year. Ecosystem Project Chained % Months Sen’s slope (pp/yr) OpenStack Nova 31.5% 175 +1.83 Neutron 10.8% 176 +2.44 Cinder 11.0% 168 +2.81 Horizon 5.1% 174 +0.76 Heat 7.5% 159 +2.23 Wikimedia mw/core 19.1% 170 +1.93 ext/Wikibase 21.9% 167 +2.76 ext/VisualEditor 13.2% 170 +1.54 ext/MobileFrontend 12.1% 170 +0.43 ops/puppet† 97.3% 170 +0.27 ONAP so 27.1% 81 −3.42 sdc 48.5% 89 −8.02 oom 16.9% 104 −1.99 cps 11.2% 65 −1.53 ccsdk/cds 25.0% 52 −1.59 †
MK p *** *** *** *** *** *** *** *** *** *** ** *** *** *
ns
ops/puppet’s near-100% prevalence reflects auto-generated config-as-code chains, not human-authored review.
Finding #1.1: Relation-chain prevalence varies across projects and ecosystems. Excluding the operations/puppet outlier, the proportion of changes in a chain ranges
A. Belhouchette, M. Chouchen, M. Chaieb, M. Hamdaqa, and A. Hamou-Lhadj
from 5.1% in OpenStack Horizon to 48.5% in ONAP sdc, with a median of 17% across the remaining 14 projects. Variation differs by ecosystem: ONAP 11–49%, OpenStack 5–32%, Wikimedia 12–22%. Chain usage is therefore not uniform but reflects differences in development practices and tooling conventions. Finding #1.2: Relation-chain adoption evolves over time, with most projects showing increasing usage. The Mann–Kendall trend test (Table 2) yields significant monotonic trends in 14 of 15 projects: 10 increasing, 4 decreasing. The only project without a significant trend is ccsdk/cds, which has the shortest observation window (38 months). All OpenStack projects exhibit increasing trends (+0.8 to +2.8 pp/yr, p < 0.001), and four of five Wikimedia projects follow the same pattern. Several ONAP projects display decreasing trends (−8.0 to −1.5 pp/yr), notably oom (Figure 4b), where monthly prevalence drops from over 60% in 2018–2019 to below 20% by 2024.
Figure 4 Monthly chain-prevalence exemplars: (a) increasing trend in OpenStack Neutron; (b) decreasing trend in ONAP oom. Bold line: 6-month rolling mean; dotted line: linear trend.
ONAP oom change 137529,4 which introduces Kafka support across multiple policy charts in a single 2024 change, illustrates this evolution. Similar cross-component modifications in earlier years were often decomposed into linked chains, suggesting a gradual shift away from chain-oriented coordination; we revisit potential explanations in Section 6. Finding #1.3: Relation chains are dominated by short pair-like structures, with project-specific deep tails and one auto-generated outlier. Per-project chaindepth statistics show similar central tendencies across ecosystems (Table 3): 12 of 15 projects have median chain depth 2, the first quartile is 2 in 14 of 15, and the third quartile is at most 4 in 11 of 15. Relation-chain activity therefore consists mostly of pair-like structures: a single dependent change on an in-review parent, or sequences of two to four members. Mean per-chain depth is correspondingly low (2.3–6.1), and standard deviation in 12 of 15 projects is below 4. The tails differ. Maximum chain depth ranges from 5 (cps) to 98 (sdc), with seven projects supporting at least one chain of depth >30. ONAP sdc has the deepest profile (mean 6.1, Q3 of 7, longest 98 members); at the other extreme, cps has maximum depth 5 and standard deviation 0.6. The ops/puppet project is an outlier: its maximum of 59,945 reflects a single auto-generated chain from its config-as-code workflow (Table 1), and we exclude it from aggregates.
4
https://gerrit.onap.org/r/c/oom/+/137529
XX:9
XX:10
How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Th
Table 3 Per-project chain-depth statistics. ops/puppet’s maximum reflects a single auto-generated config-as-code chain (Table 1). Ecosystem
Project
OpenStack nova neutron cinder horizon heat
n
Min Q1 Median Mean Q3
4,985 2,015 1,104 406 498
2 2 2 2 2
2 2 2 2 2
2 2 2 2 2
2.7 3.1 4.8 3.6 3.5
3 3 5 4 4
Wikimedia mw/core 10,036 ext/Wikibase 3,662 ext/VisualEditor 1,291 ext/MobileFrontend 1,341 ops/puppet 3,012
2 2 2 2 2
2 2 2 2 3
2 2 2 3 5
3.2 3.4 3.0 3.4 38.2
4 4 3 4 9
ONAP
2 2 2 2 2
2 2 2 2 2
2 3 2 2 2
3.2 6.1 3.4 2.3 3.5
4 7 3 2 4
so sdc oom cps ccsdk/cds
680 846 588 184 235
Max
Std
56 26 38 22 29
1.8 2.5 5.4 3.3 3.0
31 2.1 34 2.8 12 1.6 22 2.3 59,945 1244.4 21 98 46 5 18
2.3 7.8 3.6 0.6 2.7
Finding #1.4: Mean chain depth shows no systematic temporal trend in most projects. Grouping each chain by the month its base was created and computing monthly mean depth (Figure 5), Spearman correlations between calendar month and mean depth fall in −0.34 to +0.33 and are non-significant in 12 of 15 projects. The exceptions are two ONAP projects, so (ρ = −0.57, p < 0.001) and sdc (ρ = −0.53, p < 0.001), where chains have become shallower over time, consistent with their declining prevalence in Finding #1.2. OpenStack Cinder shows the opposite pattern (ρ = +0.32, p < 0.01). Outside these three cases, chain shape is stable while adoption grows: the increasing prevalence in Finding #1.2 reflects more chains, not longer ones. Finding #1.5: Depth spikes correspond to coordinated engineering campaigns, not noise. The temporal trends mask a recurring pattern in Figure 5: individual months in which mean chain depth jumps to several times the project’s long-run median. We identified 14 such spike months across the corpus (mean depth above the project’s median plus two standard deviations); 13 are multi-chain bursts where three to nineteen chains, several deep, are created together. One example is OpenStack Horizon in December 2018, when seventeen chains were created in one month with a mean depth of nine and a maximum of twenty-two: a single author decomposing a project-wide pylint cleanup5 into many dependent chains. Similar patterns recur for architectural migrations and refactoring sweeps (full list in the replication package): depth spikes mark coordinated multi-chain campaigns.
Figure 5 Monthly mean chain depth per project (6-month rolling mean; dotted line = linear trend). Horizontal dotted line at depth 2 marks the pair floor. 5
https://review.opendev.org/q/topic:pylint+project:openstack/horizon
A. Belhouchette, M. Chouchen, M. Chaieb, M. Hamdaqa, and A. Hamou-Lhadj
RQ1 summary Relation chains are a common but ecosystem coordination mechanism in Gerrit-based development, with prevalence ranging from 5% to 49% across projects (median 17%). Chain adoption is increasing in most projects. Chains are typically shallow (median depth 2), and their structural characteristics remain stable despite changing adoption rates. Deeper chains, when they occur, are associated with engineering workflows such as sequential refactoring and diagnostic branching.
5.2
RQ2: Review Outcomes
Table 5 reports descriptive statistics and Mann–Whitney effect sizes for chain-vs-solo comparisons across six metrics and five Gerrit size buckets. Table 4 breaks down the same metrics by chain-position label . Figure 6 shows per-project patchset count by chain position. Finding #2.1: Relation chains introduce synchronization overhead through additional revisions, rebasing activity, and longer review duration. Across all five Gerrit size buckets, chain members take a median of 2.6× longer to merge and undergo 1.5× more revision rounds than solo changes of comparable size (Mann–Whitney U, p < 0.001; Table 5). Cliff’s δ is small in four of five buckets and reaches large only in the XL bucket (δ = 0.49), indicating that the overhead is concentrated among very large changes rather than reflecting a full separation of distributions. This additional cost reflects synchronization overhead in dependency-linked review workflows, where developers must repeatedly coordinate rebasing, validation, and merge ordering across dependent changes. The OpenStack Horizon December 2018 pylint cleanup6 , which created seventeen dependent chains in a single month, illustrates this effect: each chain accumulated not only its own review iterations, but also coordination overhead inherited from its dependent review structure. Finding #2.2: Chain members do not attract more top-level discussion than solo changes, but receive significantly more code-anchored inline comments in OpenStack and Wikimedia. Top-level discussion volume shows no chain-vs-solo pattern: in OpenStack and Wikimedia, solo changes attract more median discussion messages than middle- or top-of-chain members (Table 4). Inline comments tell a different story. In OpenStack, chain members receive significantly more inline comments than size-matched solo changes across all five size buckets (Cliff’s δ = 0.21–0.34, all small, p < 0.001; Table 5). Wikimedia shows significant differences in every bucket but with mixed direction: chain members receive more inline comments in some buckets and fewer in others, an ecosystemspecific interaction rather than a uniform gap. ONAP shows the smallest and least consistent effect. The picture is consistent with reviewers shifting the form of feedback: top-level discussion is split across chain members, while code-anchored scrutiny stays on the changes containing the dependent edits, particularly under strict gating. The observed pattern is consistent with reviewers allocating more activity toward synchronization and validation maintenance rather than additional top-level conversational discussion. Finding #2.3: Relation chains exhibit a CI amplification effect under strict gating regimes. Chain members run a median of 10–23 CI/CD jobs depending on position, against fewer than two for solo changes in the same ecosystem (Table 4). The split is largest in OpenStack, where base, middle, and top members each trigger a test pipeline on every patchset under the project’s gating policy [27, 9]; the accumulation matches the multi-hour merge gaps reported in Finding #3.1. ONAP, with lighter CI gating, shows the smallest split (chain CI medians of 0–2 versus solo medians of 2). The OpenStack Neutron [OVN] migration
6
https://review.opendev.org/q/topic:pylint+project:openstack/horizon
XX:11
How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Th
of November 20197 , with nine dependent chains advancing the same migration, illustrates the cumulative cost: each member’s revisions retriggered the CI suite. We refer to this recurring increase in downstream validation workload as the CI amplification effect, where revisions to one chain member trigger repeated validation across dependent descendants. Table 4 Per-ecosystem chain-position breakdown of six review metrics. For each ecosystem (OpenStack, Wikimedia, ONAP), each metric is split across the three chain-position labels (Base, Middle, Top) and summarised as Min, Q1, Median, Mean, Q3, Max. ops/puppet is excluded from the Wikimedia rows (see Table 1).
7
Top
Q1
Med
Mean
Q3
Max
Min
Q1
Med
Mean
Q3
Max
Min
Q1
Med
Mean
Q3
Max
OpenStack
Middle
Min
#Revisions #Rebases Review dur. (h) Discussion msg. Inline comments CI/CD jobs
1 0 0.18 0 0 0
1 0 63.9 1 7 5
3 2 270 8 17 10
5.61 4.61 1167 30.4 38.6 21.5
6 5 990 27 40 23.2
126 125 60,844 1,796 1,786 550
1 0 0.28 0 0 0
2 1 116 0 9 6
3 2 362 4 19 14
5.72 4.72 1181 25.4 36.1 23.0
7 6 1143 19 39 28
103 102 47,431 951 935 408
1 0 0.40 0 0 0
1 0 105 0 7 5
3 2 324 4 15 11
4.78 3.78 1011 15.6 29.1 19.2
5 4 964 16 33 23
114 113 38,658 1,185 1,185 581
Wikimedia
Base Metric
#Revisions #Rebases Review dur. (h) Discussion msg. Inline comments CI/CD jobs
1 0 0 2 0 0
1 0 2.95 10 2 3
3 2 33.5 16 6 9
5.04 4.04 489 26.1 10.1 16.0
6 5 176 29 11 18
180 179 85,686 765 405 547
1 0 0.00 2 0 0
2 1 4.75 10 2 3
3 2 43.9 16 5 9
4.85 3.85 333 23.4 9.61 13.8
6 5 155 27 12 17
121 120 43,391 505 312 353
1 0 0 1 0 0
1 0 4.56 9 1 3
2 1 31.8 13 4 7
3.56 2.56 366 17.8 7.50 10.3
4 3 147 21 10 13
198 197 47,118 740 380 530
ONAP
XX:12
#Revisions #Rebases Review dur. (h) Discussion msg. Inline comments CI/CD jobs
1 0 0.00 2 0 0
1 0 2.85 8 7 0
2 1 24.4 13 11 2
3.59 2.59 203 30.3 25.0 5.22
4 3 146 29 23 6
77 76 6,353 820 748 347
1 0 0.01 2 1 0
2 1 3.52 8 8 0
2 1 29.6 11 9 0
2.95 1.95 120 16.0 14.1 1.92
3 2 117 16 14 3
50 49 4,625 567 511 96
1 0 0.02 2 0 0
1 0 3.66 7 6 0
2 1 23.3 11 9 2
2.78 1.78 122 20.4 17.2 3.16
3 2 116 19 16 4
41 40 2,562 655 604 107
https://review.opendev.org/q/topic:ovn-migration+project:openstack/neutron
A. Belhouchette, M. Chouchen, M. Chaieb, M. Hamdaqa, and A. Hamou-Lhadj
Table 5 Per-ecosystem descriptive statistics and effect sizes for review metrics, comparing chain (Ch) vs. solo (So) changes across Gerrit size buckets. p-values from Mann–Whitney U test; Cliff’s δ magnitude: N = negligible, S = small, M = medium, L = large. Min
Q1
Size Ch So
Ch
So
Ch
Mean So
Median Ch
So
Ch
Q3 So
Ch
Max So
p
Cliff’s δ
#Revisions
XS S M L XL
1 1 1 1 1
1 1 1 1 1
1 1 1 2 3
1 1 1 2 1
2.349 3.662 4.772 8.200 10.092
1.889 2.753 4.011 7.481 8.222
1 2 3 5 6
1 2 2 4 3
3 4 6 10 12
2 3 5 9 10
56 63 91 126 105
229 <0.001 89 <0.001 106 <0.001 155 <0.001 176 <0.001
0.13 (N) 0.17 (S) 0.10 (N) 0.08 (N) 0.21 (S)
#Rebases
XS S M L XL
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0.736 1.318 1.670 2.606 2.006
0.266 0.428 0.698 1.432 0.901
0 0 0 1 1
0 0 0 0 0
1 1 2 3 2.250
0 0 0 1 0
45 51 59 65 36
175 <0.001 67 <0.001 75 <0.001 66 <0.001 54 <0.001
0.20 (S) 0.27 (S) 0.26 (S) 0.23 (S) 0.33 (S)
XS 0.2 0 24.1 13.4 486.179 334.667 106.167 60.036 365.022 219.980 23673 56582.8 <0.001 0 67 26.2 798.442 539.740 213.154 116.154 672.892 401.990 32944.7 62328.2 <0.001 0 99.4 45.4 1067.866 737.522 323.892 180.072 982.629 654.940 41921.9 59373.7 <0.001 0 180.2 69.2 1646.194 1077.740 566.216 318.616 1675.422 1069.743 60844.4 58980.3 <0.001 XL 0.3 0 202.3 10.7 2081.738 643.074 755.262 95.516 2108.616 524.222 47430.6 23719.5 <0.001
0.15 (S) 0.20 (S) 0.18 (S) 0.21 (S) 0.48 (L)
Ecosystem Metric
OpenStack
S 0.2 Review dur. M 0.2 (hours) L 0.2
Discussion messages
XS S M L XL
0 0 0 0 0
0 0 0 0 0
5 7 8 11 13
6 8 9 11 8
15.485 23.843 30.613 51.410 86.777
19.556 27.665 39.130 70.236 84.590
10 14 17 25 33
11 16 20 29 24
19 29 36 59 84
23 32 44 75 79
283 368 748 1348 1786
3966 <0.001 −0.12 (N) 1777 <0.001 −0.05 (N) 3372 <0.001 −0.10 (N) 3314 <0.001 −0.07 (N) 3525 <0.001 0.09 (N)
Inline comments
XS S M L XL
0 0 0 0 0
0 0 0 0 0
0 0 0 2 2
2 4 5 8 7
12.529 14.514 17.201 37.134 89.455
17.906 24.324 33.623 62.364 82.035
4 3 4 10 20
10 12 15 23 21
15 15 16 34 98.500
22 29 37 62 76.750
288 580 752 1360 1796
3966 <0.001 −0.22 (S) 1777 <0.001 −0.31 (S) 3372 <0.001 −0.34 (M) 3314 <0.001 −0.25 (S) 3525 0.230 −0.03 (N)
CI/CD jobs
XS S M L XL
0 0 0 0 0
0 0 0 0 0
3 5 6 6 5
0 0 0 0 0
10.463 15.741 19.870 30.304 33.041
4.295 6.063 8.637 12.266 7.712
7 10 12 16 14
0 0 0 0 0
13 20 24 37 38.250
6 8 10 10 2
281 332 387 581 444
848 <0.001 276 <0.001 1344 <0.001 592 <0.001 621 <0.001
0.44 (M) 0.50 (L) 0.49 (L) 0.52 (L) 0.64 (L)
#Revisions
XS S M L XL
1 1 1 1 1
1 1 1 1 1
1 1 2 2 2
1 1 1 1 1
1.977 2.797 3.972 6.587 9.220
1.570 2.188 2.861 3.983 3.341
2 2 3 4 4
1 1 2 2 1
2 3 5 8 10
2 3 4 5 2
59 53 102 198 180
56 <0.001 81 <0.001 76 <0.001 152 <0.001 229 <0.001
0.25 (S) 0.25 (S) 0.27 (S) 0.35 (M) 0.55 (L)
#Rebases
XS S M L XL
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0.632 0.833 1.031 1.343 1.388
0.161 0.274 0.371 0.484 0.338
0 1 1 1 1
0 0 0 0 0
1 1 1 2 2
0 0 0 0 0
36 34 40 45 30
29 <0.001 36 <0.001 57 <0.001 71 <0.001 50 <0.001
0.37 (M) 0.40 (M) 0.38 (M) 0.39 (M) 0.44 (M)
XS
XL
0 0 0 0 0
0 0 0 0 0
0 0 0.6 4.5 2.6
0.2 0.4 0.3 0.1 0.2
89.256 164.258 291.977 452.677 693.852
139.776 0.193 1.576 13.016 20.944 47162.1 79040.4 <0.001 −0.25 (S) 235.849 2.222 5.796 50.216 67.619 53249.6 52312.5 <0.001 −0.11 (N) 299.865 19.830 11.239 119.545 99.448 59875.1 93770.5 <0.001 0.07 (N) 294.488 66.417 4.396 241.956 110.864 85686.3 77280.7 <0.001 0.29 (S) 145.923 59.204 0.386 311.383 6.074 40490.2 29884.2 <0.001 0.51 (L)
Discussion messages
XS S M L XL
0 0 0 0 0
0 0 0 0 0
2 2 2 3 3
2 2 2 2 0
4.194 5.686 7.576 11.941 17.220
5.868 7.119 8.454 10.535 7.265
3 4 5 7 7
6 6 6 5 1
5 7 10 14 17
8 9 11 12 5.500
185 143 159 274 405
252 <0.001 −0.25 (S) 231 <0.001 −0.12 (N) 171 <0.001 −0.03 (N) 395 <0.001 0.12 (N) 681 <0.001 0.48 (L)
Inline comments
XS S M L XL
1 1 1 1 2
1 1 1 1 1
4 5 7 9 8
6 6 6 6 4
7.109 10.309 15.200 26.174 38.059
8.834 11.319 13.778 17.419 13.606
6 8 11 16 16
7 9 10 9 6
8 12 18 32 39
10 14 17 21 10
296 200 400 740 765
252 <0.001 −0.27 (S) 317 <0.001 −0.10 (N) 303 <0.001 0.08 (N) 443 <0.001 0.28 (S) 832 <0.001 0.48 (L)
CI/CD jobs
XS S M L XL
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
2.915 4.623 7.625 14.234 20.839
2.965 4.200 5.324 6.884 6.341
3 3 4 7 7
0 0 0 0 4
4 6 10 17 18
5 6 7 6 5
282 186 309 530 547
173 <0.001 211 <0.001 261 <0.001 372 <0.001 675 <0.001
0.14 (N) 0.13 (N) 0.21 (S) 0.30 (S) 0.25 (S)
#Revisions
XS S M L XL
1 1 1 1 1
1 1 1 1 1
1 1 1 1 2
1 1 1 1 1
1.911 2.432 2.850 4.011 5.099
1.566 2.025 2.561 4.077 4.343
1 2 2 2 3
1 1 2 2 2
2 3 3 4 6
2 2 3 5 5
19 27 23 77 42
22 <0.001 47 <0.001 43 <0.001 103 0.018 72 <0.001
0.16 (S) 0.19 (S) 0.14 (N) 0.04 (N) 0.20 (S)
#Rebases
XS S M L XL
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0.567 0.764 0.802 0.953 1.081
0.181 0.248 0.327 0.457 0.503
0 1 1 1 1
0 0 0 0 0
1 1 1 1 1
0 0 0 1 0
10 10 12 18 12
17 <0.001 10 <0.001 12 <0.001 13 <0.001 23 <0.001
0.25 (S) 0.33 (M) 0.34 (M) 0.31 (S) 0.39 (M)
XS
XL
0 0 0 0 0
0 0 0 0 0
1.9 2.1 3 3.3 3.3 4.1 5.1 10.6 7 4.7
107.354 137.344 125.871 174.648 267.763
91.794 109.260 136.358 223.469 191.963
15.056 20.265 25.111 43.306 70.475
Discussion messages
XS S M L XL
0 0 1 0 0
0 0 0 0 0
6 7 7 7 9
6 7 7 7 7
12.801 15.255 16.821 24.363 25.774
12.855 16.322 18.394 27.364 26.381
8 9 10 11 14
9 9 10 13 13
13 15 16 21 26
14 17 20 31 27
181 235 268 748 473
227 0.256 −0.02 (N) 405 0.388 −0.02 (N) 430 0.460 −0.02 (N) 530 <0.001 −0.07 (N) 626 0.016 0.08 (N)
Inline comments
XS S M L XL
2 2 2 2 2
1 2 2 2 2
7 8 8 8 10
7 8 8 9 9
14.719 17.544 19.892 29.261 30.737
15.893 20.147 23.796 35.821 33.516
9 10 11 13 16
11 12 13 17 15
14 17 18 26 31
18 22 27 41 33
204 250 305 820 518
259 <0.001 −0.11 (N) 454 <0.001 −0.10 (N) 476 <0.001 −0.10 (N) 968 <0.001 −0.12 (N) 712 0.287 0.03 (N)
CI/CD jobs
XS S M L XL
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 1 2 2 2
1.918 2.289 3.071 4.897 4.964
3.038 3.824 5.402 8.457 7.135
2 2 2 2 1
2 2 3 3 2
3 3 4 5 6
3 4 6 9 7
39 44 107 347 186
64 <0.001 −0.22 (S) 74 <0.001 −0.24 (S) 108 <0.001 −0.26 (S) 543 <0.001 −0.22 (S) 164 <0.001 −0.14 (N)
Wikimedia
S Review dur. M (hours) L
ONAP
S Review dur. M (hours) L
18.035 71.062 71.606 4306.5 14296 0.331 −0.02 (N) 21.815 91.860 91.851 6031.2 14849 0.838 −0.00 (N) 24.938 118.099 117.314 4698.9 10559.6 0.603 −0.01 (N) 51.805 170.484 192.646 6353.3 10430.8 <0.001 −0.06 (N) 38.814 261.642 167.277 5582.2 5708.4 <0.001 0.12 (N)
XX:13
XX:14
How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Th
Finding #2.4: Middle-of-chain members function as synchronization bottlenecks within dependency-linked review workflows. Middle-of-chain members function as synchronization bottlenecks within dependency-linked review workflows. Across all three ecosystems, middle-of-chain changes show higher median #Revisions, more #Rebases, and longer review duration than the base or the top of the same chain (Table 4). The per-project view confirms the pattern: in nearly every project, #Revisions medians at middle positions sit at or above those at the base and the top (Figure 6). This matches bottom-up merge enforcement: a middle member is simultaneously blocked by its predecessor and blocking its successor, accumulating the iteration cost of waiting for changes below while continuing to receive feedback from above. As a result, middle members effectively function as synchronization bottlenecks that absorb the highest coordination burden within the chain. Reviewers internalise this dependency: on a 17-member ONAP sdc chain (change 886128 ), one held back approval with “waiting for parent to be verified.”
Figure 6 Patchset count by chain position-from-base, per project. Solid line: median; dashed line: mean.
RQ2 summary Relation chains introduce synchronization overhead through increased revisions, rebasing activity, review duration, and amplified CI workload compared to isolated changes (Finding #2.1). These coordination costs emerge primarily from dependency management rather than increased conversational review activity (Finding #2.2). Under strict CI-gating regimes, relation chains exhibit a CI amplification effect, where revisions to one member repeatedly retrigger validation across dependent descendants (Finding #2.3). Within chains, middle members function as synchronization bottlenecks that absorb the highest coordination burden due to simultaneous upstream and downstream dependency constraints (Finding #2.4).
5.3
RQ3: Structural Factors
Table 6 reports submission and merge gaps between consecutive chain members. Figure 7 shows Spearman correlations between base-change and descendant-mean review metrics. Finding #3.1: Chain throughput is set by the project’s CI gating regime rather than chain mechanics. Relation chains unfold in two timing regimes: a submission 8
https://gerrit.onap.org/r/c/sdc/+/88612
A. Belhouchette, M. Chouchen, M. Chaieb, M. Hamdaqa, and A. Hamou-Lhadj
gap (time between uploads of consecutive members) and a merge gap (time between merges). Submission is fast on aggregate: pooled median 14 minutes, with project medians from near-zero in OpenStack Horizon and Heat to roughly six hours in ONAP sdc and cps (Table 6); these reflect developer work patterns, since a multi-step refactor prepared offline appears within minutes while incremental uploads widen the spread. Merge gaps separate ecosystems more sharply: medians sit below one hour for most Wikimedia and ONAP projects but between two and ten hours for every OpenStack project (Horizon 2.23 h to Neutron 9.82 h). The split tracks CI-gating regimes [27, 9]: OpenStack runs a per-member test pipeline before each descendant’s submission completes, while Wikimedia and ONAP permit descendants to follow within minutes once the base has merged. The Horizon pylint cleanup of December 20189 shows this at chain level: chains assembled offline (small submission gaps) produced merge gaps in hours because each descendant waited for its predecessor’s CI pipeline on the rebased revision. The same dependency structure therefore produces substantially different coordination costs under different CI-gating regimes. Table 6 Per-project descriptive statistics of submission and merge gaps (in hours) between consecutive chain members. ops/puppet is excluded from aggregate statistics (see Table 1). Submission gap (h)
Merge gap (h)
Ecosystem
Project
Min
Q1
Med
Mean
Q3
Max
Min
Q1
Med
Mean
Q3
Max
OpenStack
nova neutron cinder horizon heat
0.00 0.00 0.00 0.00 0.00
0.00 0.00 0.00 0.00 0.00
0.10 0.56 0.36 0.00 0.00
222.7 267.6 525.9 455.6 268.6
21.06 74.75 96.41 35.78 18.12
41,640 22,172 62,353 14,003 9,691
0.00 0.00 0.00 0.00 0.00
0.02 0.06 0.01 0.04 0.06
4.62 9.82 4.35 2.23 4.81
175.2 124.1 149.8 129.5 263.2
65.80 72.69 69.50 70.95 72.62
17,956 24,983 7,079 2,520 19,390
Wikimedia
mw/core ext/Wikibase ext/VE ext/MF ops/puppet†
0.00 0.00 0.00 0.00 0.00
0.00 0.00 0.00 0.00 0.26
0.11 0.80 0.25 0.31 1.32
229.7 104.5 184.8 72.3 155.0
4.02 21.32 6.46 21.07 24.66
49,514 38,206 45,289 4,635 53,250
0.00 0.00 0.00 0.00 0.00
0.00 0.01 0.00 0.03 0.10
0.09 0.27 0.06 0.53 0.28
23.3 22.5 36.8 18.9 2.74
1.17 2.91 1.96 8.11 0.74
8,268 7,255 8,353 601 3,984
ONAP
so sdc oom cps ccsdk/cds
0.00 0.00 0.00 0.00 0.00
0.06 0.45 0.00 0.29 0.02
0.31 5.83 0.21 5.83 0.98
35.9 84.9 61.8 90.9 37.6
2.15 71.23 18.26 100.79 17.48
7,323 3,474 2,809 959 1,468
0.00 0.00 0.00 0.00 0.00
0.00 0.04 0.00 0.19 0.00
0.005 0.63 0.007 0.65 0.006
7.1 6.7 31.8 14.3 5.4
0.11 3.31 1.05 2.40 0.56
1,064 555 1,372 311 242
†
Excluded from aggregate statistics (see Table 1).
Finding #3.2: Higher review activity on base is associated with higher review activity on chain descendants. Spearman correlations between the base change’s review metrics and the mean of its descendants’ metrics are positive across all three metrics: review duration (median ρ = +0.61, significant in 15/15 projects), discussion messages (ρ = +0.60, 14/15), and #Revisions (ρ = +0.43, 15/15) (Figure 7). We refer to this regularity as the foundation effect: chains with high-effort bases have high-effort descendants, and chains with low-effort bases have low-effort descendants. Because our metrics measure review activity rather than code quality, we describe the correlation as review-effort propagation, not evidence of base quality. The Nova SDK migration chain (change 659691)10 illustrates the pattern: its base accumulated 38 #Revisions and 17 discussion messages, and its 14 merged descendants each required additional review activity.
9 10
https://review.opendev.org/q/topic:pylint+project:openstack/horizon https://review.opendev.org/c/openstack/nova/+/659691
XX:15
XX:16
How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Th
Figure 7 Foundation effect: per-chain Spearman correlation between base-change and descendantmean review metrics, computed within each project.
RQ3 summary The median merge gap between consecutive chain members varies by roughly three orders of magnitude across ecosystems and is explained by the project’s CI-gating regime rather than chain mechanics (Finding #3.1). The foundation effect: base-change review activity correlates positively with descendant review activity (Spearman ρ = 0.43–0.61) in 14–15 of 15 projects (Finding #3.2).
6
Discussions and Implications
Although many observed effect sizes are small according to Romano et al.’s Cliff’s δ thresholds, the directional consistency of the results across projects and ecosystems suggests that relation-chain membership captures recurring coordination patterns rather than isolated project-specific anomalies. Implications for Researchers. The change-level unit of analysis common in code-review research does not capture review dynamics in ecosystems where a substantial share of changes belong to chains; modern review workflows increasingly operate as dependency-aware coordination systems rather than collections of independent review units. When a chain is present, the review process involves decisions across dependent changes (which member to review first, whether to wait for a predecessor, how to handle merge ordering) invisible from any single change. Studies of reviewer load, reviewer assignment [40, 31], and review latency [47, 48] that treat reviews independently may not represent the full process, and predictive models built on change-level features alone omit chain-level signals (chain position, depth, base-change activity, chain dynamism) that our data show correlate with the same outcomes they aim to predict. Two further chain-level properties deserve attention. First, chains are not static dependency graphs but continuously evolve throughout review, a behaviour we refer to as dynamic dependency restructuring: 33.5% of chain members undergo a structural change in their parent SHA before merging, most often by detaching from an in-review parent (40% of evolution events), with rates of 25.0% (OpenStack), 39.7% (Wikimedia), and 50.2% (ONAP). Reviewers describe these dynamics in our metadata: on Wikimedia mediawiki/core
A. Belhouchette, M. Chouchen, M. Chaieb, M. Hamdaqa, and A. Hamou-Lhadj
change 53054011 , one noted that “the chain is now just blocked on the MediaWikiTestCaseBase thing,” treating the chain as a unit gated by a single member. Second, chains persist across multi-year timespans: submission gaps reach ∼4.8 years in OpenStack Nova and merge gaps ∼2.85 years in Neutron (Table 6). Chain-aware tooling must continuously recompute dependency topology throughout the review lifecycle. The foundation effect (Finding #3.2) shows base-change review activity correlates with descendant-change activity. Possible mechanisms include scrutiny applied to descendants of a heavily reviewed base, descendants inheriting architectural decisions, and reviewers accumulating context across the chain; our observational data does not distinguish between them, and because our metrics measure review activity rather than code correctness we do not interpret the correlation as evidence of base quality. LLM-based review agents [25, 41, 21] process changes independently of chain dependency, yet chain position is associated with differences in review effort (Finding #2.4) and one third of chain members restructure during review; a natural extension is to provide such tools with chain-level inputs: position, base review state, and recent dependency-graph evolution. Chain prevalence, evolution rates, and median merge gaps also vary across ecosystems by amounts comparable to chain-vs-solo differences within a single ecosystem (Findings #1.2, #3.1), correlating with submit-type and CI-gating configuration [27, 9]; replications should evaluate chain practices per setting rather than pooling across ecosystems. Implications for Practitioners. Our findings argue against the current default in review tooling, which processes each change as an independent unit [40, 31, 25, 41]: when changes belong to a relation chain, their review outcomes are quantitatively linked. The foundation effect (Finding #3.2) is the central evidence: Spearman ρ = 0.43–0.61 in 14–15 of 15 projects show base review activity predicts descendant activity. The practical consequence is a single high-leverage intervention point per chain. Concentrating reviewer attention on the base (through earlier reviewer assignment, dedicated review slots, or AI-assisted summarisation of the base’s open discussion) is associated with lower per-descendant review effort, multiplying the effect across every member. The Nova SDK migration chain (change 659691) illustrates the scale: 38 #Revisions and 17 discussion messages on the base, with 14 merged descendants each absorbing additional review activity that would likely have been smaller had the base resolved with less friction. Within chains, middle-of-chain changes show the highest median review effort (Finding #2.4), since a middle change is simultaneously blocked by its predecessor and blocking its successor. Review dashboards and reviewer-assignment systems [40, 31] could use chain position as an input, prioritising changes whose merge unblocks the largest number of downstream changes. Chain-aware CI could reorder test-resource scheduling. Consider the Horizon pylint cleanup of December 2018: its seventeen chains were assembled in one afternoon (Finding #3.1), but descendants queued behind each other for hours, each waiting for its predecessor’s CI pipeline. A chain-aware scheduler could have given higher priority to the base (gating seventeen downstream pipelines) and lower priority to any single descendant (gating none until the base merges), turning hours of serialised wait into parallel queueing once the base passes. The principle generalises: OpenStack chain members run 10–23 CI/CD jobs per position against fewer than two for solo changes (Finding #2.3), so wasted resources on superseded patchsets are a recurring property of strict-gating regimes. Finally, a chain’s dependency graph is not fixed during review: 33.5% of chain members restructure before merging, most often by detaching from an in-review parent. Tools that
11
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/530540
XX:17
XX:18
How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Th
read the graph once and assume it stable (reviewer recommendation, CI scheduling heuristics, dashboards) produce results based on a graph no longer holding in about one-third of cases. A practical mitigation is to recompute chain-dependent state on every patchset upload, not only at chain creation; the long-tail timing in Table 6 further suggests chain-aware tooling should preserve coordination state across dormant periods rather than discarding context after fixed timeouts.
7
Threats to Validity
Construct validity. We measure review effort (latency, patchset count, comment count) rather than review quality; the foundation effect is therefore framed as propagation of review activity, not of code quality. Chain detection relies on parent-SHA matching, validated against Gerrit’s Relation Chain panel, with the operations/puppet auto-generated deep chain excluded from aggregates and chain evolution distinguishing true structural changes from trivial rebases (same Change-Id). Human-vs-bot distinction in discussion and CI/CD metrics relies on a per-project allowlist; while this convention is standard in Gerrit-based MCR research [29, 46], residual misclassification at the long tail of commenters cannot be excluded. The Nova patchset-level data was extracted through a replication package rather than our own pipeline; we verified that the same Change-Id-based exclusion was applied, and removing Nova does not qualitatively change the results. Internal validity. We compare chain members and solo changes within size strata but cannot exclude task complexity as an unmeasured confounder, so the latency overhead is treated as an association rather than a causal effect [5]. We do not apply multiple-comparison corrections to per-project tests because projects are independent observational units, and the consistency of sign and magnitude across the corpus is the primary finding. External validity. The corpus spans three open-source Gerrit ecosystems, dominated by infrastructure and platform software. Industrial settings, other platforms (GitHub [48], Phabricator, Graphite), and different Gerrit submit types may exhibit different dynamics. Replication on those platforms is a natural next step.
8
Conclusion
We characterized 29,580 relation chains across 401,256 reviewed changes in three opensource Gerrit ecosystems. Chains are prevalent (5–49% of changes, increasing in 14 of 15 projects) and impose measurable coordination costs: members take a median of 2.6× longer to merge than solo changes, exhibit a CI amplification effect under strict gating, and place synchronization bottlenecks on middle members. The foundation effect (Spearman ρ = 0.43–0.61) shows base-change review activity propagates to descendants, and dynamic dependency restructuring reshapes one third of chain members mid-review, sometimes across multi-year intermittent timespans. These regularities suggest a lever for chain-aware tooling: invest review attention in base changes, and the benefit propagates through the chain. Future work should evaluate targeted interventions (base-review checkpoints, chain-aware reviewer assignment [40, 31], dependency-graph-aware CI scheduling) and replicate the analyses on platforms beyond Gerrit (Phabricator, Graphite, GitHub stacked PRs).
A. Belhouchette, M. Chouchen, M. Chaieb, M. Hamdaqa, and A. Hamou-Lhadj
9
Data Availability
To facilitate replication and extension, we share data and scripts in our replication package [1]. The package contains raw Gerrit REST API outputs for the 15 studied projects, processed per-change and per-chain CSVs used as inputs to all analyses, and Jupyter notebooks that reproduce every figure and table reported in this paper, organised by research question. A README documents environment setup and provides a finding-to-cell mapping from each result in Sections 5.1–5.3 to the specific notebook cell that produced it. References 1 2 3
4
5
6
7
8
9
10 11
12
13 14 15
Replication package for our study. Figshare, 2026. Available from: https://figshare.com/ s/9ad43e04f03c7b8f7d85. Ali Arabat et al. An ML-based approach to predicting software change dependencies: Insights from an empirical study on OpenStack. arXiv preprint arXiv:2508.05034, 2025. Ali Arabat and Mohammed Sayagh. An empirical study on cross-component dependent changes: A case study on the components of OpenStack. Empirical Software Engineering, 29(5):109, 2024. doi:10.1007/s10664-024-10488-y. Andrea Arcuri and Lionel Briand. A practical guide for using statistical tests to assess randomized algorithms in software engineering. In Proceedings of the 33rd International Conference on Software Engineering (ICSE), pages 1–10, 2011. Andrea Arcuri and Lionel Briand. A hitchhiker’s guide to statistical tests for assessing randomized algorithms in software engineering. Software Testing, Verification and Reliability, 24(3):219–250, 2014. Alberto Bacchelli and Christian Bird. Expectations, outcomes, and challenges of modern code review. In Proc. 35th International Conference on Software Engineering (ICSE), pages 712–721, 2013. Mike Barnett, Christian Bird, João Brunet, and Shuvendu K Lahiri. Helping developers help themselves: Automatic decomposition of code review changesets. In Proc. 37th International Conference on Software Engineering (ICSE), pages 134–144, 2015. Olga Baysal, Oleksii Kononenko, Reid Holmes, and Michael W Godfrey. Investigating technical and non-technical factors influencing modern code review. Empirical Software Engineering, 21(3):932–959, 2016. Nathan Cassee, Bogdan Vasilescu, and Alexander Serebrenik. The silent helper: The impact of continuous integration on code reviews. In IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER), pages 423–434, 2020. Moataz Chouchen and Ali Ouni. A multi-objective effort-aware approach for early code review prediction and prioritization. Empirical Software Engineering, 29(1):29, 2024. Moataz Chouchen, Ali Ouni, and Mohamed Wiem Mkaouer. MultiCR: Predicting merged and abandoned code changes in modern code review using multi-objective search. ACM Transactions on Software Engineering and Methodology, 33(8):1–44, 2024. Moataz Chouchen, Ali Ouni, Jefferson Olongo, and Mohamed Wiem Mkaouer. Learning to predict code review completion time in modern code review. Empirical Software Engineering, 28(4):82, 2023. Norman Cliff. Dominance statistics: Ordinal analyses to answer ordinal questions. Psychological Bulletin, 114(3):494–509, 1993. William Jay Conover. Practical nonparametric statistics. John Wiley & Sons, 3rd edition, 1999. Mattia di Biase, Ayushi Rastogi, and Alberto Bacchelli. The effects of change decomposition on code review—a controlled experiment. PeerJ Computer Science, 5:e193, 2019.
XX:19
XX:20
How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Th
16
17 18
19 20 21
22 23
24
25
26
27
28 29
30 31
32 33
Harald Gall, Karin Hajek, and Mehdi Jazayeri. Detection of logical coupling based on product release history. In Proc. International Conference on Software Maintenance (ICSM), pages 190–198, 1998. Gerrit Project. Gerrit code review: Changes, 2024. URL: https://gerrit-review. googlesource.com/Documentation/concept-changes.html. Gerrit Project. Gerrit code review: User review ui — relation chain, 2024. URL: https://gerrit-review.googlesource.com/Documentation/user-review-ui.html# related-changes. GitHub. Github stacked PRs, 2026. Native stacked pull request support, currently in private preview. URL: https://github.blog/changelog/. Graphite. Why stacked diffs lead to better code, 2024. URL: https://graphite.dev/guides/ stacked-diffs. Qi Guo, Junming Cao, Xiaofei Xie, Shangqing Liu, Xiaohong Li, Bihuan Chen, and Xin Peng. Exploring the potential of ChatGPT in automated code refinement: An empirical study. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering (ICSE), 2024. Ahmed E Hassan. Predicting faults using the complexity of code changes. In Proceedings of the 31st International Conference on Software Engineering (ICSE), pages 78–88, 2009. Toshiki Hirao, Shane McIntosh, Akinori Ihara, and Kenichi Matsumoto. The review linkage graph for code review analytics: a recovery approach and empirical study. In Proc. 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), pages 578–589, 2019. Oleksii Kononenko, Olga Baysal, and Michael W Godfrey. Code review quality: how developers see it. In Proc. 38th International Conference on Software Engineering (ICSE), pages 1028– 1038, 2016. Zhiyu Li, Shuai Lu, Daya Guo, Nan Duan, Shailesh Jannu, Grant Jenks, Deep Majumder, Jared Green, Alexey Svyatkovskiy, Shengyu Fu, et al. Automating code review activities by large-scale pre-training. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), pages 1035–1047, 2022. Laura MacLeod, Michaela Greiler, Margaret-Anne Storey, Christian Bird, and Jacek Czerwonka. Code reviewing in the trenches: Challenges and best practices. IEEE Software, 35(4):34–42, 2017. Rungroj Maipradit, Dong Wang, Patanamon Thongtanunam, Raula Gaikovina Kula, Yasutaka Kamei, and Shane McIntosh. Repeated builds during code review: An empirical study of the OpenStack community. In Proceedings of the 38th IEEE/ACM International Conference on Automated Software Engineering (ASE), pages 153–165, 2023. Henry B Mann and Donald R Whitney. On a test of whether one of two random variables is stochastically larger than the other. The Annals of Mathematical Statistics, 18(1):50–60, 1947. Shane McIntosh, Yasutaka Kamei, Bram Adams, and Ahmed E Hassan. An empirical study of the impact of modern code review practices on software quality. Empirical Software Engineering, 21(5):2146–2189, 2016. Meta. ghstack: Submit stacked diffs to GitHub. URL: https://github.com/ezyang/ghstack. Ehsan Mirsaeedi and Peter C Rigby. Mitigating turnover with code review recommendation: Balancing expertise, workload, and knowledge distribution. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering (ICSE), pages 1183–1195, 2020. Phacility. Phabricator documentation: Differential, 2024. URL: https://secure. phabricator.com/book/phabricator/article/differential/. Anand Ram, Anand Ashok Sawant, Marco Castelluccio, and Alberto Bacchelli. What makes a code change easier to review: an empirical investigation on code change reviewability. In Proc. 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), pages 201–212, 2018.
A. Belhouchette, M. Chouchen, M. Chaieb, M. Hamdaqa, and A. Hamou-Lhadj
34
35
36
37 38
39
40
41
42
43 44
45 46
47
48 49
Peter C Rigby and Christian Bird. Convergent contemporary software peer review practices. In Proc. 9th Joint Meeting on Foundations of Software Engineering (ESEC/FSE), pages 202–212, 2013. Peter C Rigby, Daniel M German, and Margaret-Anne Storey. Open source software peer review practices: a case study of the Apache server. In Proc. 30th International Conference on Software Engineering (ICSE), pages 541–550, 2008. Jeanine Romano, Jeffrey D Kromrey, Jesse Coraggio, and Jeanine Skowronek. Appropriate statistics for ordinal level data: Should we really be using t-test and Cohen’s d for evaluating group differences on the NSSE and other surveys? In Annual Meeting of the Florida Association of Institutional Research, pages 1–33, 2006. Pranab Kumar Sen. Estimates of the regression coefficient based on kendall’s tau. Journal of the American Statistical Association, 63(324):1379–1389, 1968. Patanamon Thongtanunam, Shane McIntosh, Ahmed E Hassan, and Hajimu Iida. Revisiting code ownership and its relationship with software quality in the scope of modern code review. In Proceedings of the 38th International Conference on Software Engineering (ICSE), pages 1039–1050, 2016. Patanamon Thongtanunam, Shane McIntosh, Ahmed E Hassan, and Hajimu Iida. Review participation in modern code review: An empirical study of the Android, Qt, and OpenStack projects. Empirical Software Engineering, 22(2):768–817, 2017. Patanamon Thongtanunam, Chakkrit Tantithamthavorn, Raula Gaikovina Kula, Norihiro Yoshida, Hajimu Iida, and Kenichi Matsumoto. Who should review my code? a file locationbased code-reviewer recommendation approach for modern code review. In 22nd International Conference on Software Analysis, Evolution, and Reengineering (SANER), pages 141–150, 2015. Rosalia Tufano, Simone Masiero, Antonio Mastropaolo, Luca Pascarella, Denys Poshyvanyk, and Gabriele Bavota. Using pre-trained models to boost code review automation. In Proceedings of the 44th International Conference on Software Engineering (ICSE), pages 2291–2302, 2022. Bogdan Vasilescu, Yue Yu, Huaimin Wang, Premkumar Devanbu, and Vladimir Filkov. Quality and productivity outcomes relating to continuous integration in GitHub. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE), pages 805–816, 2015. Dong Wang et al. An exploration of cross-patch collaborations via patch linkage in OpenStack. In arXiv preprint arXiv:2211.15007, 2022. Dong Wang, Raula Gaikovina Kula, Takashi Ishio, and Kenichi Matsumoto. Automatic patch linkage detection in code review using textual content and file location features. Information and Software Technology, 139:106637, 2021. Peter Weißgerber, Daniel Neu, and Stephan Diehl. Small patches get in! In Proc. 2008 International Working Conference on Mining Software Repositories (MSR), pages 67–76, 2008. Mairieli Wessel, Alexander Serebrenik, Igor Wiese, Igor Steinmacher, and Marco A Gerosa. Quality gatekeepers: Investigating the effects of code review bots on pull request activities. Empirical Software Engineering, 27(5):108, 2022. Yue Yu, Huaimin Wang, Vladimir Filkov, Premkumar Devanbu, and Bogdan Vasilescu. Wait for it: Determinants of pull request evaluation latency on GitHub. In Proceedings of the 12th Working Conference on Mining Software Repositories (MSR), pages 367–371, 2015. Xunhui Zhang, Yue Yu, Georgios Gousios, and Ayushi Rastogi. Pull request decision explained: An empirical overview. IEEE Transactions on Software Engineering, 49(2):849–868, 2022. Thomas Zimmermann, Andreas Zeller, Peter Weissgerber, and Stephan Diehl. Mining version histories to guide software changes. IEEE Transactions on Software Engineering, 31(6):429–445, 2005.
XX:21