Dans la demande d’intégration réseau pour Linux 7.3, Jakub Kicinski décrit des mainteneurs sous forte pression de revue. Son témoignage documente un volume de travail et une assistance actuelle, sans classifier avec certitude chaque contribution comme écrite par IA.
Lire l’estimation comme une estimation
La demande du 18 août donne un décompte approximatif de 632 correctifs net et 648 net-next traités par Kicinski et Paolo Abeni. Il estime qu’un tiers à la moitié de net-next ressemble à des corrections, nettoyages ou clarifications de faible priorité guidés par IA. C’est une appréciation nuancée d’un sous-ensemble, pas un étiquetage audité des 1 280 correctifs.
Il décrit aussi l’accès à plusieurs modèles avancés pour la revue, en remerciant Meta. Le texte indique que cela élimine certaines hallucinations tout en reconnaissant les limites. Il n’établit pas qu’un accord entre modèles prouve un problème, ni qu’un signalement isolé est généralement faux.
Des correctifs justes peuvent saturer la revue
Un exemple original de file d’attente rend la contrainte concrète. Supposons 30 correctifs par heure et cinq minutes d’attention humaine chacun. Deux relecteurs offrent 120 minutes de travail par heure, donc une capacité de 24 correctifs. Même si tout est valide, le stock augmente de six par heure, soit 48 sur huit heures aux mêmes rythmes.
Ces chiffres fictifs ne mesurent ni les effectifs ni les temps de netdev. Ils montrent que justesse des correctifs et rythme soutenable sont distincts. Réduire le temps de revue, les soumissions peu utiles ou augmenter la disponibilité modifie le calcul ; identifier l’outil d’écriture ne suffit pas à résoudre la contrainte.
Relier chaque signalement à des preuves vérifiables
Une note de revue utile peut identifier le chemin concerné, la condition déclenchante et l’observation distinguant défaut réel et chemin impossible. Pour une course entre opérations, nommer deux fonctions ne prouve pas qu’elles se chevauchent dans l’état concerné.
Deux modèles peuvent répéter la même hypothèse erronée. À l’inverse, un relecteur peut détecter un vrai défaut manqué par les autres. Un cas reproductible, un raisonnement sur les états et un test pertinent renseignent davantage qu’un vote entre réponses générées. C’est une méthode de revue, pas l’affirmation que toute course se reproduit facilement.
Une automatisation envisagée n’est pas une acceptation autonome
Kicinski évoque pour le cycle suivant la gestion de Patchwork, les retours de procédure courants et l’édition des messages de commit. Appliquer des changements déjà relus par des personnes de confiance reste présenté comme une possibilité. Le texte n’annonce pas l’acceptation automatique sans restriction des correctifs générés.
Les changements réseau comprennent notamment BIG TCP dans les tunnels UDP VXLAN/Geneve et une meilleure réaction de MPTCP à une forte pression mémoire. Le témoignage accompagne un travail réel du sous-système ; il ne signifie pas que Linux a confié ses décisions réseau à un agent.
Revue du 8 septembre : documentation actuelle et annonces d’origine vérifiées, explications et médias repris.