💻 computer science

How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Three Open-Source Ecosystems

Cette étude empirique de près de 30 000 chaînes de relations à travers trois écosystèmes basés sur Gerrit révèle que, bien que les séquences de changements liées par dépendance soient de plus en plus fréquentes, elles prolongent considérablement les délais de fusion et propagent l'effort de revue, nécessitant que les futurs outils et analyses de revue évoluent pour raisonner sur ces chaînes structurées plutôt que sur des changements isolés.

Auteurs originaux : Ahmed Belhouchette, Moataz Chouchen, Marouene Chaieb, Mohammad Hamdaqa Abdelwahab Hamou-Lhadj

Publié 2026-07-23

📖 8 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Ahmed Belhouchette, Moataz Chouchen, Marouene Chaieb, Mohammad Hamdaqa Abdelwahab Hamou-Lhadj

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez un monde où la construction de logiciels est comparable à l'édification d'un château massif et complexe. Dans ce monde, les développeurs ne se contentent pas de jeter des briques contre un mur en espérant qu'elles tiennent ; ils utilisent un système rigoureux appelé Revue de Code. Avant que toute nouvelle brique (ou ligne de code) ne soit ajoutée de façon permanente au château, une équipe d'inspecteurs vérifie l'absence de fissures, s'assure qu'elle correspond au design et vérifie qu'elle ne casse rien d'autre. Ce processus est vital pour maintenir le château debout et sûr.

Parfois, cependant, un projet est trop grand pour n'être qu'une seule brique. C'est une tour entière qui doit être construite. Par le passé, les développeurs auraient pu essayer de construire toute la tour d'un coup, mais cela est difficile à inspecter. Ils ont donc commencé à la décomposer en une séquence d'étapes plus petites et connectées. Dans le monde du logiciel, spécifiquement au sein d'un outil appelé Gerrit, ces étapes connectées sont appelées Chaînes de Relation. Considérez une chaîne de relation comme un ensemble de dominos debout en ligne : bien que vous ne puissiez pas renverser le troisième tant que le deuxième n'est pas tombé, et le second tant que le premier ne l'est pas, les inspecteurs peuvent vérifier tous ces éléments en même temps, mais le château ne peut être achevé que dans l'ordre. Toute la chaîne est liée ; si le premier domino (la « base ») est instable, toute la ligne est en danger. Comprendre le fonctionnement de ces chaînes est crucial car si le système est trop lent ou confus, les développeurs pourraient rester bloqués pendant des heures, ou le château pourrait être construit avec des fissures cachées.

L'effet Domino : Comment les développeurs utilisent réellement les chaînes de code

Ce document est une analyse approfondie de la manière dont les développeurs de trois communautés open-source massives (OpenStack, Wikimedia et ONAP) utilisent ces « Chaînes de Relation » pour construire des logiciels. Les chercheurs ont examiné près de 30 000 chaînes et plus de 400 000 changements de code individuels pour voir comment ces dominos liés se comportent dans le monde réel. Ils voulaient savoir : Ces chaînes sont-elles courantes ? Rendent-elles le processus de revue plus rapide ou plus lent ? Et que se passe-t-il lorsque l'on tente de réparer un domino au milieu de la ligne ?

Les chaînes sont partout (et deviennent de plus en plus grandes)

Premièrement, l'étude a révélé que ces chaînes ne sont pas un truc de niche ou rare ; elles sont une méthode de travail standard. Selon le projet, n'importe quel pourcentage compris entre 5 % et 49 % de tous les changements de code font partie d'une chaîne. En fait, dans 14 des 15 projets étudiés, l'utilisation de ces chaînes est en réalité en augmentation au fil du temps. Les développeurs réalisent que décomposer les tâches importantes en pièces plus petites et liées est la bonne approche.

La plupart de ces chaînes sont courtes, consistant généralement en une paire de dominos (un changement de base et un changement dépendant). Cependant, certains projets possèdent des chaînes qui s'étendent incroyablement loin. Les chercheurs ont trouvé des chaînes comptant jusqu'à 98 membres ! Un projet présentait même une seule chaîne auto-générée de près de 60 000 membres, bien qu'il s'agisse d'un cas spécial de configuration automatisée et non d'une écriture humaine.

Le « Milieu » est le goulot d'étranglement

C'est ici que cela devient intéressant. Les chercheurs ont découvert que se trouver au milieu d'une chaîne est le travail le plus difficile. Si vous êtes le premier domino (la « base »), vous devez simplement attendre votre propre revue. Si vous êtes le dernier (le « sommet »), vous attendez simplement ceux qui précèdent. Mais si vous êtes au milieu, vous êtes pris dans un étau. Vous êtes bloqué par le domino qui vous précède (en attendant son approbation) tout en bloquant simultanément les dominos qui suivent.

À cause de cet « étau », les changements situés au milieu d'une chaîne prennent nettement plus de temps pour être approuvés. L'étude a révélé que, en moyenne, les membres d'une chaîne mettent 2,6 fois plus de temps à être fusionnés que des changements isolés de taille identique. Ce retard n'est pas dû à une mauvaise qualité du code ; il est dû à la « surcharge de synchronisation ». Même si les inspecteurs (les relecteurs) peuvent vérifier les briques en parallèle, la fusion réelle dans le château doit se faire un par un, du bas vers le haut. Chaque fois qu'un changement dans la chaîne est modifié, cela force souvent toute la ligne à être re-vérifiée, re-testée et réordonnée, créant un goulot d'étranglement où les changements du milieu attendent ceux du dessous tout en retenant ceux du dessus.

Le monstre de l'« Amplification CI »

Le document met également en lumière un phénomène qu'ils appellent l'effet d'amplification CI. La « CI » désigne l'Intégration Continue, qui est comme une armée de robots testant automatiquement chaque nouvelle brique pour s'assurer qu'elle ne casse pas le château. Dans les projets aux règles strictes (comme OpenStack), chaque fois qu'un développeur met à jour un changement dans une chaîne, l'armée de robots doit re-tester ce changement et tous les changements qui en dépendent.

L'étude a révélé que les membres d'une chaîne déclenchent entre 10 et 23 tâches de tests automatisés, alors qu'un changement unique et isolé pourrait n'en déclencher que moins de deux. C'est comme si vous deviez tester à nouveau toute votre maison chaque fois que vous changez une simple ampoule. Cela crée une quantité massive de travail supplémentaire pour les ordinateurs et des retards pour les humains.

L'Effet de Fondation

L'une des découvertes les plus fascinantes est ce que les auteurs appellent l'Effet de Fondation. Ils ont découvert que l'effort consacré au premier domino (la base) prédit l'effort qui sera consacré à tous les dominos suivants.

Si le changement de base reçoit beaucoup d'attention, de nombreux commentaires et de nombreuses phases de révision, toute la chaîne a tendance à suivre le même mouvement. Les chercheurs ont trouvé un lien fort (une corrélation de 0,43 à 0,61) entre l'activité sur la base et l'activité sur les descendants. C'est comme si la « vibration » du premier domino donnait le ton à toute la ligne. Si la fondation est instable et nécessite beaucoup de réparations, toute la tour mettra plus de temps à être construite. Inversement, si la base est solide et approuvée rapidement, le reste de la chaîne a tendance à se dérouler sans accroc.

Les chaînes ne sont pas statiques

Enfin, le document révèle que ces chaînes ne sont pas des structures rigides. Environ 33,5 % des changements dans une chaîne subissent une « évolution structurelle » avant d'être finalement fusionnés. Cela signifie que la connexion entre les dominos change pendant leur revue. Un développeur peut décider de détacher un changement de son parent pour le lier à un autre, ou toute la chaîne peut être réorganisée.

Cela ajoute une autre couche de complexité : la carte de la chaîne est constamment en mouvement. Parfois, une chaîne peut rester inactive pendant une longue période. L'étude a montré que l'écart entre le moment où une partie d'une chaîne est soumise et son fusionnement final peut atteindre 2,85 ans dans certains cas !

Ce que cela signifie pour l'avenir

Les auteurs concluent que les outils actuels de revue de code traitent souvent chaque changement comme un événement isolé, comme si l'on regardait une brique seule sans voir le mur auquel elle appartient. Ce document suggère que nous devons changer nos outils pour comprendre la « chaîne » comme une unité globale.

Ils suggèrent que si nous concentrons notre attention sur la base de la chaîne (le premier domino), nous pouvons gagner un temps considérable pour le reste de la chaîne. Si la fondation est solide, toute la structure progresse plus vite. Ils proposent également que les outils soient plus intelligents concernant les changements du « milieu », en les priorisant peut-être pour débloquer le reste de la ligne.

En résumé, construire des logiciels avec des chaînes de relation, c'est comme diriger un orchestre complexe. Si le chef d'orchestre (la base) est à contretemps, tout l'orchestre peine. Mais si le chef est clair et que les musiciens (les outils) comprennent comment les instruments sont liés, la musique coule beaucoup plus vite. L'étude suggère qu'en comprenant ces connexions, nous pouvons cesser d'attendre notre tour et commencer à construire des châteaux de manière beaucoup plus efficace.

Résumé Technique : Comment les développeurs utilisent les chaînes de relations dans les écosystèmes de revue basés sur Gerrit

Énoncé du problème
Les flux de travail de la revue de code moderne (MCR) décomposent de plus en plus les tâches d'ingénierie complexes en séquences de changements dépendants, souvent soumis sous forme de « changements empilés » (stacked changes). Dans l'écosystème Gerrit, ces dépendances forment des chaînes de relations : des unités de revue structurées où l'état d'une revue influence directement la validation, la synchronisation et la fusion des revues dépendantes. Bien que la recherche empirique antérieure ait largement analysé la revue de code au niveau de changements isolés (en se concentrant sur la latence, la taille et la participation des réviseurs), elle a largement négligé les chaînes de relations en tant qu'artefacts de premier rang. Les études existantes modélisent soit des dépendances de dépôts par paires, s'appuient sur des annotations textuelles explicites (ex. : Depends-On), ou tracent des références de discussion, échouant ainsi à capturer les graphes de dépendance structurels qui déterminent l'ordre de fusion et la dynamique de coordination inhérente aux chaînes. Par conséquent, les analyses de revue, les outils et les systèmes assistés par l'IA opèrent sous l'hypothèse que les changements sont des unités indépendantes, manquant potentiellement des coûts de coordination critiques et des facteurs structurels qui façonnent les résultats de la revue.

Méthodologie
Les auteurs ont mené une étude empirique à travers trois écosystèmes distincts basés sur Gerrit : OpenStack, Wikimedia et ONAP. Le jeu de données comprend 401 256 changements revus et 29 580 chaînes de relations reconstruites à partir de 15 dépôts.

Extraction des données : L'étude a utilisé l'API REST de Gerrit pour extraire les métadonnées des changements, les révisions de patchsets (y compris les SHAs parents), les diffs au niveau des fichiers et les messages de revue. Les chaînes ont été détectées en liant les changements où le SHA parent d'un patchset correspondait au SHA de la dernière révision d'un autre changement en cours de revue.
Métriques : L'étude a calculé des métriques par changement (révisions, rebasages, durée de revue, messages de discussion, commentaires en ligne, tâches CI/CD) et des métriques par chaîne (profondeur, écarts de soumission, écarts de fusion). Les changements ont été stratifiés par taille (de XS à XL) pour contrôler les variables de confusion.
Analyse statistique :
- RQ1 (Usage) : Des tests de tendance de Mann–Kendall et la pente de Sen ont été utilisés pour analyser les tendances d'adoption temporelles.
- RQ2 (Résultats) : Des tests de Mann–Whitney U et le $\delta$ de Cliff ont été employés pour comparer les membres de chaînes avec des changements « solo » de taille équivalente (changements n'ayant ni parent ni enfant en cours de revue).
- RQ3 (Structure) : Des corrélations de Spearman ont analysé la relation entre l'activité du changement de base et l'activité moyenne des descendants.
Portée : L'analyse est observationnelle ; les effets rapportés sont interprétés comme des associations plutôt que des conséquences causales.

Contributions clés et résultats

1. Prévalence et structure (RQ1)

Adoption : Les chaînes de relations sont prévalentes, allant de 5 % à 49 % des changements selon les projets, avec une médiane de 17 %. L'adoption est en augmentation dans 14 des 15 projets étudiés.
Profondeur : Les chaînes sont principalement peu profondes. La profondeur médiane est de 2 (une base et un descendant) dans 12 des 15 projets. Bien que des chaînes profondes existent (par exemple, une profondeur maximale de 98 dans ONAP sdc), elles sont des cas isolés rares.
Stabilité : Malgré une adoption croissante, la forme structurelle (profondeur) des chaînes reste stable au fil du temps. Les chaînes profondes correspondent généralement à des campagnes d'ingénierie coordonnées (ex. : campagnes de refactorisation) plutôt qu'à du bruit.

2. Résultats de la revue : Chaîne vs Solo (RQ2)

Surcharge de synchronisation : Les membres de chaînes mettent en moyenne 2,6 fois plus de temps à être fusionnés que les changements solo de taille équivalente. Cette surcharge est plus prononcée pour les changements très volumineux (taille XL), où le $\delta$ de Cliff atteint 0,49 (effet important).
Activité de revue : Les membres de chaînes n'attirent pas plus de messages de discussion de haut niveau que les changements solo. Cependant, dans OpenStack et Wikimedia, ils reçoivent significativement plus de commentaires en ligne ancrés au code, suggérant un déplacement de la forme du feedback plutôt que de son volume.
Amplification CI : Sous des régimes de contrôle CI stricts (ex. : OpenStack), les chaînes de relations présentent un effet d'amplification CI. Les membres de la chaîne déclenchent 10 à 23 tâches CI/CD par position, contre moins de deux pour les changements solo. Les révisions d'un membre déclenchent la revalidation de tous les descendants dépendants.
Goulots d'étranglement : Les membres du milieu de chaîne font office de goulots d'étranglement de synchronisation, absorbant l'effort de revue le plus élevé (révisions, rebasages, durée) car ils sont simultanément bloqués par leurs prédécesseurs et bloquent leurs successeurs.

3. Facteurs structurels intra-chaîne (RQ3)

Le contrôle CI dicte le débit : Le temps entre les fusions (écart de fusion) est déterminé par le régime de contrôle CI du projet plutôt que par la mécanique de la chaîne. Les projets OpenStack présentent des écarts de fusion de 2 à 10 heures dus aux pipelines de test par membre, tandis que les projets Wikimedia et ONAP fusionnent souvent en quelques minutes une fois la base approuvée.
L'effet de fondation : Il existe une forte corrélation positive ( $\rho = 0,43–0,61$ ) entre l'activité de revue du changement de base et l'activité moyenne de ses descendants. Les chaînes avec des bases à fort effort entraînent systématiquement des descendants à fort effort, suggérant que l'effort de revue se propage à travers le graphe de dépendance.
Restructuration dynamique : Les chaînes ne sont pas statiques. 33,5 % des membres de chaîne subissent un changement structurel de leur SHA parent avant la fusion (ex. : détachement d'un parent en cours de revue), ce qui se produit souvent en cours de revue.
Longévité : Les chaînes peuvent persister sur des périodes de plusieurs années, les écarts de fusion atteignant jusqu'à 2,85 ans dans certains cas.

Signification et affirmations
L'article soutient que les chaînes de relations sont des unités de coordination durables, façonnées par l'écosystème, possédant des structures internes que les analyses centrées sur le changement ne peuvent capturer. Les auteurs affirment que :

L'outillage actuel est mal aligné : L'outillage de revue par défaut, qui traite les changements indépendamment, ne tient pas compte de la surcharge de synchronisation, de l'amplification CI et des dynamiques structurelles des chaînes.
Les modèles prédictifs sont incomplets : Les modèles prédisant la latence ou l'effort de revue basés uniquement sur les caractéristiques du changement omettent des signaux critiques au niveau de la chaîne (position, activité de la base, évolution des dépendances) qui sont corrélés aux résultats.
Intervention stratégique : L'« Effet de fondation » suggère un point d'intervention à fort levier : concentrer l'attention de la revue sur le changement de base peut propager les bénéfices (réduction de la friction) à l'ensemble de la chaîne.
Directions futures : Les auteurs appellent à des analyses de revue conscientes des chaînes, des systèmes d'assignation de réviseurs qui priorisent les changements débloquant le plus grand sous-graphe descendant, et des agents de revue assistés par l'IA qui se conditionnent sur la position dans la chaîne et l'état du changement de base.

L'étude conclut que la compréhension de ces structures de dépendance est essentielle pour des analyses de revue précises et des outils efficaces dans les écosystèmes de génie logiciel modernes et à grande échelle.