Linux 7.2-rc7 est sorti le 9 août, et le chiffre qui compte si vous planifiez des montées de version est celui du calendrier : Linus Torvalds attend la 7.2 finale le week-end prochain, autour du 16 août, sauf mauvaise surprise d'ici là. La candidate elle même porte environ 400 commits hors fusion touchant 412 fichiers, ce qui est beaucoup pour une septième candidate. Torvalds explique pourquoi sans détour. Ce sont surtout de petites corrections, une bonne part remontées par la revue avec des outils d'IA, et il qualifie ce volume de nouvelle normalité plutôt que de signal d'alarme. Pour qui suit les sorties du noyau, cette nuance est toute l'histoire.
The short answer
Linux 7.2-rc7 est sorti le 9 août et se révèle inhabituellement lourd pour une candidate tardive. Linus Torvalds attribue cette taille au volume de petites corrections qui arrivent désormais de la revue par des outils d'IA, et parle d'une nouvelle normalité plutôt que d'un problème de version. L'essentiel des changements s'étale finement sur les pilotes, les systèmes de fichiers et le cœur réseau, avec le matériel cryptographique s390 et l'infrastructure btrfs comme exceptions concentrées. Il ne prévoit pas de report : la 7.2 finale est attendue autour du 16 août, et elle est pressentie comme noyau par défaut d'Ubuntu 26.10 et d'autres sorties d'automne.
La septième candidate d'un cycle du noyau est censée être ennuyeuse. À ce stade, la fenêtre de fusion est fermée depuis six semaines, le travail intéressant est dans l'arbre depuis assez longtemps pour avoir cassé quelque chose de visible, et il ne doit rester qu'une fine couche de corrections. Linux 7.2-rc7, sortie le 9 août, n'est pas fine. Elle porte environ 400 commits hors fusion sur 412 fichiers, et Torvalds a ouvert son annonce en pointant cette taille avant toute autre chose.
Son explication mérite une deuxième lecture. La plupart des changements sont de petites corrections, et une large part existe parce que des outils de revue par IA les ont trouvées. Selon ses termes, il ne peut pas dire qu'il soit enchanté par la taille de tout cela, mais c'est comme ça, la nouvelle normalité avec beaucoup de correctifs, dont beaucoup dus à la revue par divers outils d'IA. Il a aussi noté que rien ne paraissait particulièrement inquiétant en soi. Il y en a simplement beaucoup.
Le volume et le risque se sont dissociés
Aussi loin que la plupart d'entre nous suivons les sorties du noyau, la taille d'une candidate tardive servait d'indicateur approximatif de ce qui allait mal. Une rc7 calme signifiait que le cycle s'était bien passé. Une rc7 grasse signifiait que quelque chose était entré à moitié fini pendant la fenêtre de fusion et se faisait réparer en public.
Cet indicateur ne tient plus, et c'est le point réellement utile de l'annonce.
La revue automatisée n'attend pas un rapport de bogue. Elle lit du code que personne n'a regardé depuis des années, dans des pilotes pour du matériel que possède encore une poignée de gens, et elle produit une petite correction valide pour un chemin d'erreur mal géré que personne n'allait déclencher. Ces correctifs sont du vrai travail et améliorent l'arbre. Ils arrivent aussi en continu, y compris tard dans la fenêtre de stabilisation, ce qui veut dire qu'une candidate tardive peut être grosse parce que la couverture a augmenté, pas parce que la qualité a baissé.
Les développeurs du noyau utilisent des vérificateurs automatisés depuis vingt ans, la catégorie n'est donc pas nouvelle. Coccinelle réécrit des motifs dans l'arbre depuis 2008 et syzkaller alimente un flux régulier de rapports de plantage depuis des années. Ce qui a changé, c'est l'ampleur. Un outil capable de lire n'importe quel pilote, plutôt qu'un outil qui reconnaît un motif prédéfini, couvre une fraction très différente de 43 millions de lignes.
Ce qui est concentré, et ce qui est étalé
La répartition compte plus que le total, et elle se vérifie facilement.
L'essentiel de la rc7 s'étale finement sur les pilotes, les systèmes de fichiers et le cœur réseau, ce qui est la forme la moins intéressante qu'une candidate puisse prendre. Une répartition fine, ce sont de nombreuses petites corrections indépendantes, et aucune d'entre elles n'est une raison de changer vos plans.
Les exceptions méritent l'attention. Les corrections pour le matériel cryptographique s390 sont concentrées, ce qui concerne une population restreinte et précise qui fait tourner Linux sur des grands systèmes IBM. Btrfs a restauré une infrastructure retirée plus tôt dans le cycle, un travail que nous avons traité quand le fixup worker COW est revenu. Une restauration tardive dans un cycle mérite d'être notée d'une façon dont cent corrections de pilotes ne le méritent pas, parce qu'elle signifie qu'une décision prise pendant la fenêtre de fusion s'est révélée mauvaise sous charge réelle.
La date de sortie, voilà ce qui est actionnable
Torvalds a dit ne pas prévoir de report sauf apparition d'un problème sérieux avant le week-end. Cela place la Linux 7.2 finale autour du 16 août.
Pour la plupart des lecteurs, cette date est un coup de départ plutôt qu'une livraison. Les distributions à publication continue porteront la 7.2 en quelques jours à quelques semaines. Les distributions à versions figées se gèlent sur un noyau et le conservent, et la 7.2 est prévue comme défaut d'Ubuntu 26.10 et d'autres sorties d'automne : le calendrier qui gouverne vos machines est donc celui de la distribution. Les distributions d'entreprise sont un monde à part, qui rétroportent sur une base plus ancienne sans suivre les numéros amont.
Ce que nous ferions
Rien d'urgent, et une petite chose.
Si vous exploitez des serveurs de production, attendez. Les candidates existent pour qu'un groupe restreint prenne le risque d'abord, et il n'y a aucun avantage à en faire partie par accident. La version finale plus quelques semaines d'empaquetage par votre distribution reste le bon point d'entrée.
Si vous maintenez quoi que ce soit qui touche aux interfaces du noyau, modules hors arbre, pile de stockage que vous avez réglée vous même, configuration de déport réseau, ou pilotes que vous compilez, c'est la dernière semaine utile. Tester après la version finale, c'est découvrir votre problème en même temps que tout le monde, sans fenêtre restante pour faire remonter un correctif. Une machine de test qui fait tourner la candidate sur une charge ressemblant à la vôtre suffit.
Et à la prochaine annonce, lisez le diffstat plutôt que le chiffre du titre. Dans un cycle où la revue automatisée génère des correctifs à ce rythme, le nombre de commits a cessé de signifier ce qu'il signifiait.
Sources et pour aller plus loin
- Linux 7.2-rc7 released following another exhausting AI driven week, Phoronix, 10 août 2026
- AI reviews bring new normal to Linux release candidates, Slashdot, 10 août 2026
- Couverture de la sortie de Linux 7.2-rc7, LinuxCompatible
- Linux kernel 7.2-rc1 released, 43 millions de lignes, OSTechNix
- La page d'accueil de kernel.org
Questions fréquentes
Une candidate plus grosse veut-elle dire que Linux 7.2 sera moins stable ?
Pas en soi, et Torvalds a pris soin de le dire. Son résumé de la rc7 était que rien ne semblait particulièrement inquiétant en tant que tel, il y en avait simplement beaucoup. Une candidate vous dit deux choses : combien a changé, et à quel point les changements sont alarmants. Ces deux grandeurs bougent indépendamment. Une candidate tardive pleine de corrections d'une ligne dans des pilotes n'est pas le même animal qu'une candidate tardive contenant un sous système réécrit, même si le diffstat est identique. Ce qui a changé dans ce cycle, c'est que le flux de corrections est alimenté par la revue automatisée autant que par les rapports de bogues humains, donc le volume ne mesure plus ce qui était cassé. Lisez le shortlog plutôt que le compteur si vous voulez le vrai signal.
Que signifie concrètement que des corrections viennent d'outils de revue par IA ?
Que l'analyse statique est devenue assez peu coûteuse pour tourner sur l'arbre entier plutôt que sur les zones que quelqu'un soupçonnait. Les mainteneurs du noyau utilisent des vérificateurs automatisés depuis vingt ans, Coccinelle et les différents fuzzers syzkaller parmi eux, donc la catégorie n'est pas neuve. Ce qui est neuf, c'est la couverture et le volume. Un modèle qui lit un pilote que personne n'a audité depuis 2014 et signale une valeur de retour mal gérée produit un correctif réel, petit, et qui n'aurait probablement jamais été écrit autrement. Multipliez cela par des milliers de pilotes et vous obtenez exactement le motif décrit par Torvalds : beaucoup de corrections individuellement banales qui arrivent en continu, y compris tard dans la fenêtre de stabilisation, quand l'arbre est censé être calme.
Quand Linux 7.2 arrivera-t-il vraiment sur ma distribution ?
Plus tard que vous ne le pensez, et c'est normal. La sortie amont attendue autour du 16 août est le point de départ, pas la date de livraison. Les distributions à publication continue embarquent d'ordinaire un nouveau noyau en quelques jours à quelques semaines. Les distributions à versions figées choisissent un noyau au moment du gel et le portent toute la durée de vie de cette version, et Linux 7.2 est pressenti comme noyau par défaut d'Ubuntu 26.10 entre autres, ce qui veut dire que le calendrier qui vous concerne est celui de la distribution, pas celui du noyau. Les distributions d'entreprise sont encore plus loin, puisqu'elles rétroportent des correctifs sur une base plus ancienne sans suivre du tout les numéros de version amont. Un uname sur la machine vous dit où vous en êtes réellement.
Faut-il tester la candidate ou attendre la version finale ?
Testez la candidate si vous maintenez quelque chose qui touche aux interfaces du noyau : modules hors arbre, piles de stockage, configurations de déport réseau, ou tout pilote que vous compilez vous même. Attendre la version finale, c'est découvrir votre problème en même temps que tout le monde, sans temps restant pour le remonter en amont tant qu'un correctif peut encore passer. Pour un parc de serveurs et de postes ordinaires, attendre est le bon choix. Il n'y a aucun bénéfice à faire tourner une candidate en production, et tout l'intérêt de la série des candidates est qu'un groupe restreint absorbe le risque d'abord. Le juste milieu utile, c'est une machine de test qui suit les candidates et reproduit votre charge réelle d'assez près pour être instructive.
Comment lire une annonce de candidate sans lire tous les commits ?
Commencez par le résumé du diffstat en tête d'annonce, qui vous dit comment le changement se répartit. Des corrections étalées finement dans les pilotes constituent le cas le moins intéressant et le plus fréquent. C'est la concentration qui mérite l'attention : un sous système qui représente une part démesurée d'une candidate tardive est soit en train de se remettre d'une régression, soit réparé dans l'urgence, et les deux méritent d'être connus si vous en dépendez. Dans la rc7, la répartition portait surtout sur les pilotes, les systèmes de fichiers et le cœur réseau, avec le matériel cryptographique s390 et l'infrastructure btrfs comme exceptions concentrées. Cela prend deux minutes et vous donne l'essentiel de la valeur d'une lecture complète.