Depuis plus de trois décennies, le noyau Linux fonctionne avec une réalité aussi évidente qu’inconfortable : la décision finale concernant les changements à intégrer dans la branche principale repose généralement sur une seule personne. Linus Torvalds, créateur du projet et mainteneur « final » depuis 1991, a – en pratique – été le point de référence ultime pour un processus mondial impliquant des centaines de développeurs et plus d’une centaine de mainteneurs.
Désormais, et pour la première fois de manière explicitement formalisée, la communauté a documenté une procédure de continuité pour le dépôt canonique du noyau : un plan conçu pour être déclenché uniquement si le mainteneur principal ne peut (ou ne souhaite) plus assumer ce rôle, et en l’absence d’une transition « ordonnée » et normale.
Un « plan pour le plan », mais déjà écrit
Ce nouveau document, intégré à la documentation officielle du noyau, s’appuie sur une observation précise : Linux est un projet fortement réparti, où chaque sous-système a ses responsables, mais l’étape finale – intégrer les changements dans mainline – reste centralisée. Le document rappelle même qu’il y a eu des précédents où d’autres personnes ont effectué ce travail lorsque cela a été nécessaire (notamment lors du cycle de la version 4.19 en 2018).
L’essentiel n’est pas tant de découvrir qu’il existe une vie après Torvalds – la communauté en est consciente – mais plutôt de formaliser comment on décide du « qu’est-ce qu’on fait maintenant » dans un scénario exceptionnel. Dans le monde de l’entreprise, cela s’appelle la planification de la succession. En génie logiciel, cela se résume souvent à une métrique très brute : le bus factor.
Que déclenche le protocole ?
Ce processus est conçu comme une voie d’urgence. Il ne s’activerait que si ceux qui maintiennent le dépôt principal deviennent « incapables ou non désireux » de continuer à exercer cette responsabilité, et si aucune transition n’est facilitée.
Dans ce cas, une figure de référence est nommée, le Organizer, qui par défaut serait l’organisateur du dernier Maintainers Summit. Si cela n’est pas possible, le plan prévoit en second ressort le président du Technical Advisory Board (TAB) de la Linux Foundation.
Le calendrier : 72 heures, 15 mois et deux semaines
Le dispositif est volontairement simple, avec des délais précis :
- En 72 heures, le Organizer doit lancer une discussion avec les personnes invitées au dernier Maintainers Summit.
- Si plus de 15 mois» se sont écoulés depuis le dernier Maintainers Summit, le TAB désigne les invités (ce groupe pouvant inclure d’autres mainteneurs si nécessaire).
- Ce groupe doit se réunir (en ligne ou en personne) « aussi vite que possible » pour évaluer les options pour la gestion du dépôt principal, en privilégiant la santé à long terme du projet et de sa communauté.
- Dans un délai de deux semaines, un représentant communique via la liste de diffusion ksummit (liée au Maintainers Summit) les prochaines étapes.
De plus, le document affirme que la Linux Foundation – guidée par le TAB – soutiendra et mettra en œuvre ce que cette procédure déterminera.
Ce que cela signifie (et ne signifie pas) pour Linux
Ce mouvement n’est ni une annonce de retrait ni un « changement imminent ». C’est, avant tout, une marque de maturité : reconnaître qu’un projet critique pour Internet, le cloud et l’industrie ne peut dépendre du maintien de l’inertie, si un jour la figure centrale venait à manquer.
C’est aussi un message adressé à l’extérieur. Dans un contexte où la résilience de la chaîne d’approvisionnement logicielle est scrutée de près, formaliser des processus de continuité réduit l’incertitude pour les entreprises, gouvernements et écosystèmes entiers qui bâtissent leurs produits et services autour de Linux.
Ce qui est intéressant, c’est que ce plan ne crée pas une nouvelle « constitution » pour le noyau : il s’appuie sur des structures déjà existantes (le Maintainers Summit, le TAB) et sur un mécanisme classique de la communauté (le consensus et la communication publique via les listes de diffusion). Il est délibérément minimaliste : il fixe la façon de déclencher une décision collective lorsque le temps presse.
Questions Fréquentes
Est-ce que cela signifie que Linus Torvalds se retire du kernel ?
Non. La procédure est envisagée comme une mesure de précaution pour un scénario exceptionnel. Elle ne prévoit ni calendrier ni transition active.
Qui désignera le remplaçant en cas d’imprévu ?
Le processus prévoit qu’un Organizer (le dernier organisateur du Maintainers Summit ou, à défaut, le président du TAB de la Linux Foundation) entame la démarche, et la décision est discutée avec le groupe d’invités du dernier Maintainers Summit (ou ceux désignés par le TAB s’il n’y a pas eu de cime récemment).
Pourquoi parle-t-on autant du « bus factor » dans ce contexte ?
Car le développement du noyau repose sur un flux distribué, mais une intégration finale centralisée. Formaliser un plan de continuité augmente la résilience du projet face à des événements inattendus.
Où la décision sera-t-elle communiquée publiquement ?
Le plan prévoit qu’au maximum deux semaines après sa mise en marche, la suite soit annoncée via la liste de diffusion ksummit (liée au Maintainers Summit).
