Linus Torvalds explose face aux commits « pollués » : quand les balises link transforment l’historique Git du noyau Linuxen une décharge numérique ingérable
Le créateur de Linux ne mâche pas ses mots : dans une récente discussion sur la liste de diffusion du noyau, Linus Torvalds a exprimé son exaspération face à l’usage « poubelle » des balises « link » insérées dans les messages de commits Git. Pour lui, ce champ censé documenter les correctifs est devenu un fourre-tout inutile, encombré de doublons et de références mal structurées. Mais derrière ce coup de gueule se cache une question plus large : comment maintenir la qualité d’un projet open source qui fédère des milliers de contributeurs aux pratiques très variées ?
Pour un projet de la taille du noyau Linux, chaque détail de la documentation compte. Les commits Git sont bien plus qu’un simple journal des modifications : ils constituent une archive collective, la mémoire vivante du projet. L’introduction des balises « link » devait répondre à un besoin légitime : relier un patch à une discussion technique, un bug report ou une proposition de modification sur les listes de diffusion.
Mais dans les faits, le champ « link » est devenu un fourre-tout. Au lieu d’apporter de la clarté, il est encombré de doublons, de redirections inutiles et de liens peu pertinents. Certains développeurs y ajoutent plusieurs références qui pointent toutes vers la même discussion, d’autres insèrent des URL génériques sans valeur ajoutée. Le résultat est un bruit documentaire qui fait perdre du temps à ceux qui doivent analyser ou auditer le code.
Pour Torvalds, cette situation est intolérable. Car si un projet de cette envergure tolère des pratiques relâchées, c’est l’ensemble de la traçabilité qui se fragilise.
Il a commenté une demande de modification :
Envoyé par Linus Torvalds
Et bon sang, cette modification contient cet argument prometteur « Link : » qui, je l'espérais, expliquerait pourquoi cette modification inutile existe, mais COMME TOUJOURS, ce lien n'a fait que me faire perdre mon temps en renvoyant vers les mêmes informations qui étaient déjà là.
J'espérais qu'il renverrait vers un rapport d'erreur ou quelque chose qui expliquerait pourquoi ma réaction initiale était erronée.
Arrêtez avec ces conneries. Arrêtez d'ajouter des arguments Link inutiles qui font perdre du temps aux gens.
Ajoutez le lien s'il contient des informations SUPPLÉMENTAIRES.
Bon sang, je déteste vraiment ces liens inutiles. J'adore voir des liens utiles, mais 99 % des liens que je vois ne renvoient qu'à des conneries stupides et inutiles, et cela ne fait que me faire perdre mon temps. ENCORE.
Je n'ai donc pas retiré cela, je suis agacé de devoir même regarder cela, et si vous vous attendez vraiment à ce que je retire cela, je veux une vraie explication et pas un lien inutile.
Oui, je suis grincheux. J'ai l'impression que mon travail principal - en fait mon seul travail - consiste à essayer de donner un sens aux demandes de retrait, et c'est pourquoi je déteste absolument ces choses qui sont ajoutées automatiquement et qui ne font que rendre mon travail plus difficile.
J'espérais qu'il renverrait vers un rapport d'erreur ou quelque chose qui expliquerait pourquoi ma réaction initiale était erronée.
Arrêtez avec ces conneries. Arrêtez d'ajouter des arguments Link inutiles qui font perdre du temps aux gens.
Ajoutez le lien s'il contient des informations SUPPLÉMENTAIRES.
Bon sang, je déteste vraiment ces liens inutiles. J'adore voir des liens utiles, mais 99 % des liens que je vois ne renvoient qu'à des conneries stupides et inutiles, et cela ne fait que me faire perdre mon temps. ENCORE.
Je n'ai donc pas retiré cela, je suis agacé de devoir même regarder cela, et si vous vous attendez vraiment à ce que je retire cela, je veux une vraie explication et pas un lien inutile.
Oui, je suis grincheux. J'ai l'impression que mon travail principal - en fait mon seul travail - consiste à essayer de donner un sens aux demandes de retrait, et c'est pourquoi je déteste absolument ces choses qui sont ajoutées automatiquement et qui ne font que rendre mon travail plus difficile.
Torvalds : « un lien sans discussion, c’est juste du bruit inutile dans l’historique Git »
Pour Torvalds, le problème n’est pas tant la présence de liens que leur usage « automatique et idiot », qui finit par polluer l’historique. Il estime qu’il faudrait au minimum un mécanisme pour décourager cette pratique, et dans un monde idéal un modèle plus intelligent pour insérer les références : « Dans un monde parfait, lâche-t-il, on aurait un système capable de placer automatiquement un lien utile – pas cette avalanche de redondances collées partout dans l’historique. »
Selon lui, il serait bien plus pertinent d’associer un lien au message de merge d’une série de commits, où il apporte du contexte, plutôt que de polluer chaque commit individuel. Il cite l’exemple d’une série de commits : au lieu de répéter le même lien dans chaque message, il serait bien plus pertinent de l’intégrer dans le message de merge associé à la lettre de couverture. Cela, tranche-t-il, serait « utile et bien moins agaçant ».
Il va plus loin : à ses yeux, un lien ne devrait apparaître que s’il y a eu une discussion réelle autour d’un patch. « Un renvoi vers un vrai fil de débat, même stérile, vaut toujours mieux qu’un lien vers un mail appliqué sans commentaire », martèle-t-il. Et avec ironie, il ajoute qu’il faudrait peut-être laisser l’IA s’occuper de trier ces cas, puisque, après tout, « c’est ce que certaines fiches de poste imposent aujourd’hui ».
Sa conclusion est sans appel : tant que les liens n’apportent rien de concret, ils ne font que transformer les commits Git en dépotoir documentaire, au détriment de la clarté et de la traçabilité.
Envoyé par Linus Torvalds
Quoi qu'il en soit, « décourager une utilisation inconsidérée » pourrait se résumer à un simple message d'avertissement indiquant que le lien risque d'ajouter une charge supplémentaire fastidieuse.
À l'inverse, un modèle « parfait » pourrait consister à mettre en place une sorte d'automatisation « sauf si cela a fait l'objet d'une discussion réelle ».
Mais je pense qu'un tel modèle serait beaucoup trop compliqué, à moins que quelqu'un ne souhaite explorer l'utilisation de l'IA parce que sa description de poste stipule « Rechercher des utilisations réellement utiles de l'IA »Dans le monde technologique actuel, je suppose que de telles descriptions de poste existent. Soupir.
Par exemple, étant donné que « b4 » finit de toute façon par parcourir le fil de discussion en aval d'un patch afin d'ajouter des lignes « acked-by », etc., je pense qu'en théorie, il pourrait y avoir une heuristique du type « il y a eu une discussion animée sur ce patch particulier, donc un lien en vaut réellement la peine ».
En théorie.
À l'inverse, un modèle « parfait » pourrait consister à mettre en place une sorte d'automatisation « sauf si cela a fait l'objet d'une discussion réelle ».
Mais je pense qu'un tel modèle serait beaucoup trop compliqué, à moins que quelqu'un ne souhaite explorer l'utilisation de l'IA parce que sa description de poste stipule « Rechercher des utilisations réellement utiles de l'IA »Dans le monde technologique actuel, je suppose que de telles descriptions de poste existent. Soupir.
Par exemple, étant donné que « b4 » finit de toute façon par parcourir le fil de discussion en aval d'un patch afin d'ajouter des lignes « acked-by », etc., je pense qu'en théorie, il pourrait y avoir une heuristique du type « il y a eu une discussion animée sur ce patch particulier, donc un lien en vaut réellement la peine ».
En théorie.
Les solutions possibles : automatisation, formation ou police des commits ?
Le coup de gueule de Torvalds relance un vieux débat : comment améliorer la qualité documentaire sans décourager les contributions ? Plusieurs pistes existent. Certains suggèrent de renforcer les règles d’acceptation des commits, en refusant systématiquement ceux qui comportent des balises « link » redondantes. D’autres plaident pour l’automatisation : mettre en place des scripts ou des hooks Git capables de détecter les doublons et de signaler les abus.
Une autre option serait de renforcer la pédagogie, en expliquant aux contributeurs la valeur d’une documentation concise et pertinente. Mais dans un projet où la pression du temps est forte et où les patchs affluent quotidiennement, le pari de la formation est difficile à tenir.
Au final, le choix se résume à une question de gouvernance : faut-il privilégier la fluidité des contributions ou la rigueur documentaire ? Linus Torvalds, fidèle à lui-même, penche clairement pour la seconde option.
Une polémique qui dépasse Linux
L’affaire des « link » est loin d’être anecdotique. Elle illustre un problème qui touche l’ensemble des grands projets open source. De Kubernetes à Chromium, en passant par les projets de fondations comme Apache, tous font face à la même difficulté : concilier ouverture maximale et cohérence documentaire.
La multiplication des références, des systèmes de suivi (GitHub, GitLab, mailing lists, bug trackers), et des contributeurs rend la traçabilité de plus en plus complexe. Dans ce contexte, la frustration exprimée par Torvalds résonne comme un avertissement : sans règles claires et respectées, les grands projets risquent de voir leur mémoire collective s’effriter.
La sortie de Torvalds met aussi en lumière un dilemme culturel propre à l’open source. L’ouverture implique d’accepter la diversité des pratiques, des styles et des niveaux de rigueur. Mais cette diversité peut entrer en collision avec l’exigence de qualité et de lisibilité qu’impose un projet de long terme.
Trop de discipline peut décourager les contributeurs occasionnels. Trop de tolérance peut ruiner la cohérence du projet. L’équilibre est fragile, et chaque communauté doit le définir selon son ADN. Pour Linux, Torvalds rappelle que la barre doit rester haute : la discipline documentaire n’est pas un luxe, mais une nécessité.
Comparaison avec d’autres grandes communautés open source
La sévérité de Torvalds contraste avec d’autres cultures du logiciel libre. Chez Mozilla, par exemple, les règles de commit sont également strictes, mais l’accent est mis sur l’accompagnement des contributeurs. Les revues de code servent de filtre qualitatif, et la documentation Git est structurée pour encourager les bonnes pratiques plutôt que sanctionner les mauvaises.
À l’Apache Software Foundation, la gouvernance est plus collégiale : les comités de projet fixent leurs propres règles, souvent plus souples. Cela favorise la diversité et la contribution large, mais peut aussi conduire à une hétérogénéité documentaire qui complique la maintenance.
Dans le cas de Chromium, projet piloté par Google mais ouvert à la communauté, un équilibre est recherché via des outils automatisés : la validation des commits repose largement sur des bots capables de vérifier le style, la cohérence et les métadonnées. L’humain intervient moins, et le système compense les écarts de rigueur par une infrastructure logicielle robuste.
Linux, lui, reste fidèle à une philosophie incarnée par Torvalds : la discipline est d’abord culturelle et humaine. Elle se transmet par l’exemple et par des rappels parfois musclés, quitte à froisser les sensibilités.
Source : Linus Torvalds (1, 2)
Et vous ?
Les balises « link » doivent-elles être encadrées par des règles strictes de formatage, quitte à ralentir la fluidité des contributions ? Peut-on comparer le « style Torvalds » à une forme de culture d’entreprise appliquée à l’open source, et est-ce un modèle durable ? Le noyau Linux, projet critique pour l’économie mondiale, doit-il être géré avec plus de rigueur que d’autres projets open source comme Apache ou Mozilla ? À l’inverse, une trop grande discipline ne risque-t-elle pas de décourager les contributeurs occasionnels ou les nouveaux venus ? Est-ce aux mainteneurs de faire la police des commits, ou doit-on laisser la communauté s’autoréguler ? Le problème des « link » n’est-il pas révélateur d’un défi plus large : comment documenter efficacement des projets géants qui brassent des millions de lignes et des milliers de développeurs ?
Vous avez lu gratuitement 245 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.