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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.