Résumé

  • L’admission d’un correctif dans une branche stable est un contrôle au niveau du patch ; le maintien à long terme d’une version ancienne pose une question distincte de capacité.
  • Kernel.org relie cette durée aux besoins des acteurs en aval et au temps des mainteneurs : une échéance prévisionnelle ne vaut donc pas engagement commercial.

Une ancienne version du noyau peut rester utile à un appareil bien après sa sortie initiale. Cela ne signifie ni que tout correctif lui sera rétroporté, ni que sa branche restera suivie aussi longtemps que le produit sera vendu. Linux applique ici deux filtres différents ; les confondre transforme un label pratique en promesse trompeuse.

Le premier filtre porte sur chaque correctif. Les règles du noyau stable demandent que la correction, ou une solution équivalente, existe déjà dans la branche principale. Elle doit être manifestement correcte et testée, ne pas dépasser 100 lignes avec le contexte, respecter les règles de soumission et résoudre un problème réel ou ajouter un identifiant de périphérique. Les exemples cités comprennent les plantages, blocages, corruptions de données, vrais problèmes de sécurité, particularités matérielles et erreurs de compilation. Les règles écartent les risques théoriques sans explication d’exploitabilité ainsi que les changements sans bénéfice pour l’utilisateur. Ces limites rendent le rétroportage plus facile à examiner et réduisent le risque d’introduire une nouvelle panne dans une branche déjà utilisée. Les règles de la branche stable détaillent les critères et les voies de soumission.

Passer ce filtre ne dispense pas de revue. La procédure documentée place les candidats acceptés dans une file, les soumet à des développeurs et au mainteneur du sous-système concerné, puis teste le résultat dans des versions candidates. Une objection peut faire retirer un patch. Le passage préalable par la branche principale est donc une exigence de provenance, et non la promesse automatique que chaque ancienne série recevra la correction. Celle-ci doit encore s’appliquer correctement à la version visée et résister à sa revue.

Le second filtre concerne la durée de vie de la branche. Kernel.org décrit les versions à support long comme des arbres plus anciens qui reçoivent les corrections de bogues importantes, généralement moins fréquemment que les versions stables actives. Sa documentation cite les grandes nouveautés, les besoins des distributions commerciales, la demande des fabricants d’appareils, la charge de travail et la disponibilité des mainteneurs parmi les critères de sélection. Une nouvelle version à support long commence avec une échéance prévisionnelle qui peut être prolongée si l’intérêt de l’industrie contribue à soutenir la maintenance. Cette échéance n’est pas fixe. La page consultée pour cet article porte la date du 25 février 2026 : son explication de la politique reste utile, mais son tableau des versions ne constitue pas un état des lieux d’octobre 2026. La page des versions de Kernel.org décrit ces critères et cette politique de projection.

C’est là que le rôle de Greg Kroah-Hartman compte, sans faire de lui tout le système. La Linux Foundation le présente comme Fellow, mainteneur de la branche stable de Linux et de plusieurs sous-systèmes. Le document consacré au processus de développement nomme Greg et Sasha Levin dans l’équipe stable, tout en indiquant que les mainteneurs concernés et les évaluateurs prennent part à la revue des patches. Dans un entretien publié en 2018, Greg se souvient avoir fait partie des développeurs volontaires au lancement des versions stables, en 2005. Il dit que le nombre d’arbres suivis simultanément a ensuite augmenté et relie ce travail à la sécurité des appareils déjà en service. C’est son témoignage rétrospectif, pas un décompte actuel des branches ni la preuve qu’il choisit seul chaque version à support long. Le profil de la Linux Foundation, le document sur le processus du noyau et l’entretien de Greg précisent son rôle et ses limites.

Pour un opérateur, cette distinction change la portée d’un label de support. Une branche à support long de kernel.org est une ligne de maintenance communautaire. Une distribution peut livrer un noyau qui en dérive, ajouter ses propres changements ou suivre un autre calendrier. Kernel.org renvoie les utilisateurs de noyaux de distribution vers le canal d’assistance de leur éditeur et précise que les développeurs du noyau peuvent ne pas prendre en charge ces versions. Il faut donc savoir qui maintient exactement le noyau installé, quel processus couvre les correctifs de sécurité et les régressions, et si l’engagement du fournisseur couvre la durée d’exploitation du produit. Le label LTS ne répond à aucune de ces questions contractuelles. La FAQ de Kernel.org et sa page des versions distinguent ces périmètres.

Le mécanisme économique est simple, mais un numéro de version peut le masquer. Chaque série conservée demande du travail : quelqu’un doit évaluer les correctifs, vérifier les rétroportages, tester les versions et intervenir lorsqu’une régression apparaît. Les sources publiques ne chiffrent pas ce travail. Elles montrent en revanche que les besoins en aval et la disponibilité des mainteneurs pèsent sur le choix des lignes suivies plus longtemps. La demande de l’industrie peut justifier l’effort ; elle ne remplace pas les personnes qui l’accomplissent.

La Note 64 de Heng Lu propose un test analytique utile : un document de coordination peut décrire un état futur sans le rendre opérationnel à lui seul. Cet article ne présente pas Linux comme un système conçu selon cette note. Utilisée comme simple grille de lecture, cette distinction aide à comprendre pourquoi les mots « long terme » et une date prévisionnelle ne constituent pas une garantie auto-exécutoire. Ils décrivent un dispositif qui doit continuer à être adopté et entretenu. La Note 64 est une référence analytique, pas une source sur les règles du noyau.

Analyse

Les deux filtres répartissent le risque à des niveaux différents. Les règles de patch limitent ce qui peut entrer dans une branche existante ; la sélection des versions à support long limite le nombre d’anciennes séries que la communauté peut continuer à porter. Un filtre plus strict ne crée pas des années de disponibilité humaine, et une forte demande de l’industrie ne rend pas sûr un rétroportage non examiné. L’engagement concret n’existe que si le correctif et la capacité de maintenir sa branche restent tous deux viables.

L’horizon dépend donc d’une coalition qui peut évoluer. Les fabricants ont besoin d’anciens noyaux pour des appareils déjà déployés ; les distributions peuvent vouloir une base stable pour une version ; les mainteneurs doivent disposer de temps pour examiner et tester le travail. Les sources publiques ne décrivent ni la répartition de ces contributions ni le poids de négociation de chaque acteur. Elles indiquent toutefois que la durée du support dépend de la demande et du travail disponible, et non de l’âge du numéro de version.

Sources