C’est vraiment ambivalent. D’un côté, c’est excellent. Je me demande qui n’a jamais subi une réunion de nettoyage du backlog où l’on avance en grattant depuis le haut, tout en sachant qu’on n’arrivera jamais au bout ; la sensation est franchement misérable.
D’un autre côté, les issues n’ont pas disparu, seul leur tag a changé ; si tout est une question de tags et de tri, ne vaut-il pas mieux laisser faire le flux plutôt que chercher à contrôler cette quasi-utopie qu’est une liste d’issues parfaitement vide ? Il y a sûrement aussi des avantages à laisser ces notes visibles. C’est un peu comme lors d’un grand ménage : on a décidé de jeter quelque chose, mais l’inconscient nous souffle de le garder parce qu’on pourrait en avoir besoin plus tard.
Malgré tout, dans l’ensemble, je suis plutôt pour. Au minimum, cela devrait apporter un sentiment de libération et l’effet de recharge nécessaire pour aborder de nouvelles issues.
Pour ajouter un peu de contexte, le créateur est en train de procéder à une réécriture complète.
Il aurait sans doute été plus propre de publier d’abord la version réécrite, puis de fermer les anciennes issues comme deprecated. Les issues de la branche de réécriture auraient pu être séparées par des tags de version. Si on les ferme alors que la nouvelle version n’est pas encore terminée, des contributeurs pourraient ouvrir de nouvelles issues sur l’ancienne version sans savoir qu’elle n’est plus prise en charge.
Cela dit, il ne s’agit pas d’ignorer les issues ni de laisser des problèmes dans la base de code : l’ensemble du projet est en cours de remise à plat. https://twitter.com/jdalton/status/1571863497969119238
Du point de vue utilisateur, si ce type de « nettoyage » signifie fermer des issues, c’est problématique. Si le problème existe toujours dans le produit, il devrait rester ouvert, ne serait-ce que pour la documentation et pour permettre aux utilisateurs confrontés au même souci de le trouver facilement et d’y ajouter des informations.
Je trouve plus honnête qu’un projet reconnaisse l’existence des issues et les garde ouvertes. Côté développeur, si le nombre d’issues dérange, mieux vaut utiliser un filtre pour masquer les vieilles issues peu importantes.
Je suis partagé moi aussi. D’un côté, chaque fois que je reviens à du travail en JavaScript, je vais chercher lodash. De l’autre, je pense qu’un peu moins de la moitié de cette bibliothèque devrait vraiment se trouver dans la bibliothèque standard.
Ce n’est pas justement le genre de tâche où les grands modèles de langage devraient être bons ? Je parle de résumer les tickets.
C’est pour ça que Basecamp ne maintient pas de backlog. Ce qui est important finit par refaire surface.
jwz a dit ceci :
Je pense que c’est la manière la plus courante dont les bugs que je signale à des projets open source sont fermés. Vous signalez un bug, il reste non lu pendant un an, parfois deux, puis un jour le module est réécrit à partir de zéro. Et le nouveau mainteneur n’a aucune envie de vérifier si la nouvelle version corrige effectivement les problèmes connus de l’ancienne version.
Pour un projet avec peu de mainteneurs, voire un seul, il me semble plus raisonnable que les rapporteurs de bugs consacrent chacun 10 à 15 minutes à vérifier si le problème existe encore, plutôt que le mainteneur unique y passe des jours ou des semaines.
C’est particulièrement vrai pour les bugs difficiles ou complexes à reproduire : on ne sait même pas si le mainteneur pourra les reproduire dans son environnement, et la personne qui les a signalés est probablement plus habituée à les observer.
S’il y a une équipe plus importante, ou s’il s’agit d’un projet associé à un service commercial, l’équilibre peut être un peu différent.
Ce que l’on voit dans beaucoup de projets libres/open source, c’est que très peu de gens sont prêts à retrousser leurs manches, mais qu’en même temps ils consacrent beaucoup de temps à expliquer à quel point le projet leur est indispensable, à faire des demandes et à proposer toutes sortes de choses.
La plupart créent une nouvelle issue pour signaler une liste de souhaits, ou laissent un rapport de bug très vague. Certains produisent de bons rapports de bugs, mais leur volonté de contribuer s’arrête généralement là.
Personnellement, je n’ai pas la disposition nécessaire pour maintenir un projet, car je ne suis pas prêt à gérer diplomatiquement la plupart des commentaires que l’on voit souvent.
Cela dit, pour les issues que je signale, j’essaie toujours de faire ma part : remonter à la cause et, si possible, soumettre une PR qui corrige le problème.
Il existe aussi une variante : une issue est signalée pour une version majeure, puis quand une nouvelle version majeure sort, on ferme toutes les issues des anciennes releases au motif que le problème pourrait ne plus exister, même s’il ne s’agit pas d’une réécriture mais seulement de changements progressifs.
Il suffit de créer une PR contenant un test qui devrait passer, mais qui est pour l’instant marqué comme ignoré. Ainsi, lors de la reconstruction, on dispose d’un chemin simple pour vérifier l’état d’avancement et voir si les choses s’améliorent.
Si un problème vous tient vraiment à cœur, il faut y ajouter un test.
Les découvertes de sécurité sont parfois traitées de cette manière aussi.
Mon expérience est la même avec les projets logiciels à code fermé.
John-David Dalton, l’auteur de lodash, a écrit [ceci l’an dernier][1] :
Pour la réécriture de lodash, je déclare la faillite de la dette technique. On repart de zéro avec TypeScript et Rollup. Pas de wrapper FP. Cette mode est terminée. Condoléances aux collègues de la personne qui a introduit cette plaie dans la base de code. Ce n’est absolument pas adapté aux équipes ni aux humains.
Je ne sais pas si cela correspond à 100 %, mais ça semble assez proche.
[1]: https://twitter.com/jdalton/status/1571863497969119238
« Cette mode est terminée. Condoléances aux collègues de la personne qui a introduit cette plaie dans la base de code. Ce n’est absolument pas adapté aux équipes ni aux humains » — mais l’auteur initial, ce n’est pas lui ?
On dirait que quelqu’un d’autre a ajouté la complexité qu’il critique. Si c’est lui qui l’a introduite, il semble en parler non pas comme d’un retour d’expérience ou d’un apprentissage, mais comme s’il avait développé le projet en suivant une mode, et que maintenant que cette mode est passée, il était temps de passer à la suivante.
C’était quoi, le wrapper FP, et de quelle mode s’agissait-il ?
Je ne connais pas bien les enjeux côté JavaScript, mais dans ce contexte, quel est le problème avec la programmation fonctionnelle ?
Bien joué
Rien qu’en regardant quelques PR en tête de liste, on trouve ce genre de choses :
ajouter un mot dans un commentaire, ajouter un fichier de configuration pour promouvoir un service de développement, remplacer var par let, modifier le comportement bien établi d’une fonction cœur, supprimer des points-virgules, etc.
La plupart ont sans doute été ouvertes avec la bonne intention d’améliorer la bibliothèque, mais, à un moment donné, pour le mainteneur, cela devient simplement du spam ou, pire, une charge qui augmente le sentiment de culpabilité à mesure qu’il n’arrive plus à s’en occuper.
Tout comme les célébrités engagent des gardes du corps et voyagent en première classe ou en jet privé pour échapper à une attention constante et préserver leur santé mentale, je me demande quelles mesures seraient possibles pour les grands projets open source.
Personnellement, en tant que mainteneur open source, les PR que je préfère sont celles qui corrigent des fautes de frappe, reformulent du texte ou font du refactoring automatique. Elles demandent très peu d’effort de revue, donc je les fusionne presque toujours très vite.
Celles qui prennent le plus de temps sont les PR qui implémentent de grosses fonctionnalités. Elles nécessitent beaucoup de revue et de discussions, donc j’ai tendance à repousser leur examen détaillé.
Pendant un temps, il y a eu une mode consistant à ouvrir des PR mineures sur des projets connus. J’y vois une tentative de remplir un CV.
Il y avait un utilisateur GitHub en particulier qui soumettait à répétition, sur plusieurs projets JavaScript, des PR se contentant de remplacer var par let.
Ça donnait l’impression qu’il cherchait à remplir son profil GitHub.
Waouh
Je commençais à m’intéresser au passage de mes packages à Bun, mais j’hésitais à cause de la compatibilité et de la question de savoir si Bun allait vraiment durer. Je m’étais aussi un peu brûlé avec « Modern Yarn ». Mais voir lodash franchir le pas me donne envie d’y réfléchir plus sérieusement.
C’est effectivement une grosse nouvelle. D’autant plus si l’on considère que, malgré la récente sortie de la v1.0, il y a des problèmes de performances sous Windows.
J’essaie d’éviter de dire aux développeurs open source comment gérer leurs projets. Je suis moi-même développeur open source, et ça m’agace quand d’autres me le font.
Mais si j’avais été un utilisateur ayant passé pas mal de temps à rédiger une issue et à aider à résoudre un problème, ou quelqu’un ayant travaillé sur un correctif ou une nouvelle fonctionnalité puis envoyé une PR, je pense que je serais assez découragé maintenant.
Mais la plupart des utilisateurs ne consacrent qu’un temps minime à rédiger une issue. La plupart des rapports de bugs sont médiocres.
Les issues ont été fermées, elles n’ont pas disparu. Si elles sont encore pertinentes, elles pourront probablement être redemandées plus tard.
La faillite d’issues est bien réelle. D’après mon expérience personnelle, à un moment donné, maintenir de l’open source devient difficilement compatible avec une vie dans le monde réel.
Le travail est gratuit et souvent peu reconnu. Pas toujours, bien sûr. Le problème, c’est qu’il est complexe et qu’il entre en concurrence avec les responsabilités concrètes comme le travail, la famille et le repos. Les gens s’énervent facilement, cherchent régulièrement la dispute ou demandent qu’on lise la documentation à leur place. Quand un projet open source est connu, il s’accompagne aussi d’une énorme responsabilité.
Je m’attends à un grand effondrement de l’écosystème open source lorsque les personnes qui dirigent ces projets diront « ça suffit » et partiront faire des choses plus importantes.
Je comprends ça. Ces temps-ci, j’en viens même à penser qu’un projet personnel non trivial ressemble davantage à une addiction ou à de l’automutilation qu’à un vrai projet.
Cela dit, l’écosystème open source est follement inefficace. Il y a lodash, underscore et d’innombrables autres bibliothèques, alors qu’elles n’ont pas toutes besoin d’exister. Il existe aussi beaucoup de bibliothèques qui ne font qu’une seule chose, et ce sont généralement des sous-ensembles de ce type de bibliothèques.
La plupart sont utilisées avec des minificateurs et du tree shaking, et les fonctionnalités inutilisées sont supprimées. Même les bibliothèques lourdes s’optimisent facilement et sont surtout composées de parties séparées, donc on n’a pas forcément besoin d’une bibliothèque légère, et l’effort de développement augmente globalement de façon linéaire.
S’il n’y avait pas le fait que les programmeurs aiment par-dessus tout l’élégance et la simplicité, et veulent constamment tout réécrire pour l’améliorer ne serait-ce qu’un peu, je pense que l’open source aurait assez de main-d’œuvre même si tout le monde n’y consacrait qu’un quart du temps qu’il y consacre actuellement.
Lodash est une excellente bibliothèque. Je finis par en utiliser un peu dans presque tous les projets sur lesquels je travaille
Mais à mesure que JavaScript s’améliore, j’utilise de moins en moins Lodash. À chaque fois que je m’en sers, je vérifie s’il existe une fonctionnalité intégrée pour ce que je veux faire. Il m’arrive aussi assez souvent de commenter des PR avec un lien en disant « ça n’a pas besoin de Lodash »
J’espère malgré tout que ce n’est pas le signe que le projet est en train de se retirer
C’est clairement pratique, mais au final, si j’en ai besoin, je pense que je préférerais une version maison des utilitaires
Je suis tout à fait d’accord. La syntaxe de décomposition, littéralement le simple ..., a eu un effet énorme. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Les helpers d’itérateurs devraient aussi être déployés bientôt, ce qui aidera beaucoup. Les helpers d’itérateurs asynchrones devraient prendre du retard pendant un bon moment. https://github.com/tc39/proposal-iterator-helpers
Avant, j’avais l’impression de devoir utiliser .apply() plusieurs fois par semaine dans la base de code sur laquelle je travaillais, pour appeler des fonctions de manière créative. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Maintenant tout cela a disparu, et je dirais qu’il y a une chance sur deux que 50 % des membres de l’équipe connaissent .call et .apply
Chrome 117 intègre Object.groupBy(), et cela devrait beaucoup aider à supprimer nombre des derniers cas qui poussent à utiliser lodash. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Je n’utilise plus lodash ni underscore.js depuis 8 ans. Je ne vois pas vraiment ce qu’on ne peut pas faire facilement avec map, filter, find, etc.
Un outil de suivi des issues sert en réalité à deux choses qui se recoupent. D’un côté, c’est un moyen pour les mainteneurs de suivre ce qu’ils ont à faire ; de l’autre, c’est un moyen pour la communauté au sens large et les utilisateurs de suivre les défauts du logiciel
Déclarer une « faillite des issues » a du sens pour le premier usage, mais pour le second, cela revient à effacer des informations précieuses sur des problèmes qui existent dans la version actuelle
1 commentaires
Avis sur Hacker News
C’est vraiment ambivalent. D’un côté, c’est excellent. Je me demande qui n’a jamais subi une réunion de nettoyage du backlog où l’on avance en grattant depuis le haut, tout en sachant qu’on n’arrivera jamais au bout ; la sensation est franchement misérable.
D’un autre côté, les issues n’ont pas disparu, seul leur tag a changé ; si tout est une question de tags et de tri, ne vaut-il pas mieux laisser faire le flux plutôt que chercher à contrôler cette quasi-utopie qu’est une liste d’issues parfaitement vide ? Il y a sûrement aussi des avantages à laisser ces notes visibles. C’est un peu comme lors d’un grand ménage : on a décidé de jeter quelque chose, mais l’inconscient nous souffle de le garder parce qu’on pourrait en avoir besoin plus tard.
Malgré tout, dans l’ensemble, je suis plutôt pour. Au minimum, cela devrait apporter un sentiment de libération et l’effet de recharge nécessaire pour aborder de nouvelles issues.
Il aurait sans doute été plus propre de publier d’abord la version réécrite, puis de fermer les anciennes issues comme deprecated. Les issues de la branche de réécriture auraient pu être séparées par des tags de version. Si on les ferme alors que la nouvelle version n’est pas encore terminée, des contributeurs pourraient ouvrir de nouvelles issues sur l’ancienne version sans savoir qu’elle n’est plus prise en charge.
Cela dit, il ne s’agit pas d’ignorer les issues ni de laisser des problèmes dans la base de code : l’ensemble du projet est en cours de remise à plat.
https://twitter.com/jdalton/status/1571863497969119238
Je trouve plus honnête qu’un projet reconnaisse l’existence des issues et les garde ouvertes. Côté développeur, si le nombre d’issues dérange, mieux vaut utiliser un filtre pour masquer les vieilles issues peu importantes.
jwz a dit ceci :
C’est particulièrement vrai pour les bugs difficiles ou complexes à reproduire : on ne sait même pas si le mainteneur pourra les reproduire dans son environnement, et la personne qui les a signalés est probablement plus habituée à les observer.
S’il y a une équipe plus importante, ou s’il s’agit d’un projet associé à un service commercial, l’équilibre peut être un peu différent.
Ce que l’on voit dans beaucoup de projets libres/open source, c’est que très peu de gens sont prêts à retrousser leurs manches, mais qu’en même temps ils consacrent beaucoup de temps à expliquer à quel point le projet leur est indispensable, à faire des demandes et à proposer toutes sortes de choses.
La plupart créent une nouvelle issue pour signaler une liste de souhaits, ou laissent un rapport de bug très vague. Certains produisent de bons rapports de bugs, mais leur volonté de contribuer s’arrête généralement là.
Personnellement, je n’ai pas la disposition nécessaire pour maintenir un projet, car je ne suis pas prêt à gérer diplomatiquement la plupart des commentaires que l’on voit souvent.
Cela dit, pour les issues que je signale, j’essaie toujours de faire ma part : remonter à la cause et, si possible, soumettre une PR qui corrige le problème.
Si un problème vous tient vraiment à cœur, il faut y ajouter un test.
John-David Dalton, l’auteur de lodash, a écrit [ceci l’an dernier][1] :
On dirait que quelqu’un d’autre a ajouté la complexité qu’il critique. Si c’est lui qui l’a introduite, il semble en parler non pas comme d’un retour d’expérience ou d’un apprentissage, mais comme s’il avait développé le projet en suivant une mode, et que maintenant que cette mode est passée, il était temps de passer à la suivante.
Bien joué
Rien qu’en regardant quelques PR en tête de liste, on trouve ce genre de choses :
ajouter un mot dans un commentaire, ajouter un fichier de configuration pour promouvoir un service de développement, remplacer
varparlet, modifier le comportement bien établi d’une fonction cœur, supprimer des points-virgules, etc.La plupart ont sans doute été ouvertes avec la bonne intention d’améliorer la bibliothèque, mais, à un moment donné, pour le mainteneur, cela devient simplement du spam ou, pire, une charge qui augmente le sentiment de culpabilité à mesure qu’il n’arrive plus à s’en occuper.
Tout comme les célébrités engagent des gardes du corps et voyagent en première classe ou en jet privé pour échapper à une attention constante et préserver leur santé mentale, je me demande quelles mesures seraient possibles pour les grands projets open source.
Celles qui prennent le plus de temps sont les PR qui implémentent de grosses fonctionnalités. Elles nécessitent beaucoup de revue et de discussions, donc j’ai tendance à repousser leur examen détaillé.
varparlet.Ça donnait l’impression qu’il cherchait à remplir son profil GitHub.
La nouvelle la plus importante, c’est que Lodash passe de Node.js à Bun : https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d...
Je commençais à m’intéresser au passage de mes packages à Bun, mais j’hésitais à cause de la compatibilité et de la question de savoir si Bun allait vraiment durer. Je m’étais aussi un peu brûlé avec « Modern Yarn ». Mais voir lodash franchir le pas me donne envie d’y réfléchir plus sérieusement.
J’essaie d’éviter de dire aux développeurs open source comment gérer leurs projets. Je suis moi-même développeur open source, et ça m’agace quand d’autres me le font.
Mais si j’avais été un utilisateur ayant passé pas mal de temps à rédiger une issue et à aider à résoudre un problème, ou quelqu’un ayant travaillé sur un correctif ou une nouvelle fonctionnalité puis envoyé une PR, je pense que je serais assez découragé maintenant.
Ils ont fermé 363 issues avec le label
issue bankruptcy: https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Acl...Même chose pour 325 PR : https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed...
La faillite d’issues est bien réelle. D’après mon expérience personnelle, à un moment donné, maintenir de l’open source devient difficilement compatible avec une vie dans le monde réel.
Le travail est gratuit et souvent peu reconnu. Pas toujours, bien sûr. Le problème, c’est qu’il est complexe et qu’il entre en concurrence avec les responsabilités concrètes comme le travail, la famille et le repos. Les gens s’énervent facilement, cherchent régulièrement la dispute ou demandent qu’on lise la documentation à leur place. Quand un projet open source est connu, il s’accompagne aussi d’une énorme responsabilité.
Je m’attends à un grand effondrement de l’écosystème open source lorsque les personnes qui dirigent ces projets diront « ça suffit » et partiront faire des choses plus importantes.
Cela dit, l’écosystème open source est follement inefficace. Il y a lodash, underscore et d’innombrables autres bibliothèques, alors qu’elles n’ont pas toutes besoin d’exister. Il existe aussi beaucoup de bibliothèques qui ne font qu’une seule chose, et ce sont généralement des sous-ensembles de ce type de bibliothèques.
La plupart sont utilisées avec des minificateurs et du tree shaking, et les fonctionnalités inutilisées sont supprimées. Même les bibliothèques lourdes s’optimisent facilement et sont surtout composées de parties séparées, donc on n’a pas forcément besoin d’une bibliothèque légère, et l’effort de développement augmente globalement de façon linéaire.
S’il n’y avait pas le fait que les programmeurs aiment par-dessus tout l’élégance et la simplicité, et veulent constamment tout réécrire pour l’améliorer ne serait-ce qu’un peu, je pense que l’open source aurait assez de main-d’œuvre même si tout le monde n’y consacrait qu’un quart du temps qu’il y consacre actuellement.
Lodash est une excellente bibliothèque. Je finis par en utiliser un peu dans presque tous les projets sur lesquels je travaille
Mais à mesure que JavaScript s’améliore, j’utilise de moins en moins Lodash. À chaque fois que je m’en sers, je vérifie s’il existe une fonctionnalité intégrée pour ce que je veux faire. Il m’arrive aussi assez souvent de commenter des PR avec un lien en disant « ça n’a pas besoin de Lodash »
J’espère malgré tout que ce n’est pas le signe que le projet est en train de se retirer
..., a eu un effet énorme. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Les helpers d’itérateurs devraient aussi être déployés bientôt, ce qui aidera beaucoup. Les helpers d’itérateurs asynchrones devraient prendre du retard pendant un bon moment. https://github.com/tc39/proposal-iterator-helpersAvant, j’avais l’impression de devoir utiliser
.apply()plusieurs fois par semaine dans la base de code sur laquelle je travaillais, pour appeler des fonctions de manière créative. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Maintenant tout cela a disparu, et je dirais qu’il y a une chance sur deux que 50 % des membres de l’équipe connaissent.callet.applyChrome 117 intègre
Object.groupBy(), et cela devrait beaucoup aider à supprimer nombre des derniers cas qui poussent à utiliser lodash. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...map,filter,find, etc.Un outil de suivi des issues sert en réalité à deux choses qui se recoupent. D’un côté, c’est un moyen pour les mainteneurs de suivre ce qu’ils ont à faire ; de l’autre, c’est un moyen pour la communauté au sens large et les utilisateurs de suivre les défauts du logiciel
Déclarer une « faillite des issues » a du sens pour le premier usage, mais pour le second, cela revient à effacer des informations précieuses sur des problèmes qui existent dans la version actuelle