Tu dis "les deux se défendent" comme s'il y avait deux positions discrètes, le tout-va et le toujours-nickel. En pratique il y a un continuum et on peut être "plus souple" ou "plus strict" sans passer d'un extrême à l'autre.
Bien sûr. Mais comme c'est une histoire de philosophie de maintenance, on rencontre souvent les extrêmes.
C'est marrant (et j'imagine, le hasard) car justement le journal qui te suit parle de cela, mais de l'autre point de vue.
Pieter Hintjens est un développeur récemment décédé et ce serait sa pensée qu'il explique dans des articles:
En partant de ces postulats, il considère qu'une architecture parfaite est secondaire. D'autant plus qu'elle repose déjà sur un grand bazar (pas une de vos dépendances n'est codée pareil). Par conséquent, lorsqu'on réalise un projet communautaire, toute contribution est bonne à prendre. Il nous invite à donc à être laxiste sur les conditions d'acceptation d'un patch. Ainsi, on permet une plus grande participation. Une intelligence collective se met en œuvre. Le groupe peut proposer des solutions plus pertinentes et adaptées. L'ensemble des intervenants est plus motivé. Ce qui attire plus de monde et diversifie la communauté. Elle passe ainsi dans un état propice à la résolution pertinente de problèmes.
C'est vraiment à l'inverse de ce qu'on fait dans un logiciel qui va contrôler plus sérieusement les patchs. Même s'il y a aussi un entre-deux possible, ici on voit plus des philosophies opposées. C'est pour ça que je fais ce genre de séparation (même si tu as raison). Ensuite je comprends bien ce point de vue laxiste aussi et je pense qu'il marche mieux pour les plus petits projets (petit notamment en nombre de lignes/fichiers). Pourquoi? Parce qu'un peu de bordel est acceptable dans ce cas. Ça reste lisible. Pour lancer un projet, c'est sûrement idéal même d'être très laxiste sur la revue de patch. Je n'étais pas là à l'époque, mais je suis sûr que ça a dû être le cas au début de GIMP aussi.
De nos jours, GIMP est un projet gigantesque en terme de fichiers, lignes de code, et fonctionnalité. Et pourtant il est globalement extrêmement bien organisé. L'architecture sépare bien les diverses parties du code (le "core" fonctionnel, les actions, la peinture, la gestion de fichier, les opérations graphiques, le GUI... et bien plus de sous-séparations encore). Le style de code est plutôt bien respecté partout (rendant le code très lisible). Etc.
Si on se mettait à accepter un patch qui casse nos diverses règles juste parce qu'il "marche", je pense que ce serait le début de la fin et qu'au bout d'un an, le code ne serait plus aussi maintenable.
C'est pas parfait mais c'est une base de code étonnamment bonne pour un projet de 21 ans. En fait je me rends compte que pas mal de gros projets sur lesquels j'ai contribué ont des bases globalement saines, alors que beaucoup de petits projets sont des bordels sans nom. Cela correspondrait donc à mon intuition comme quoi le laxisme du réviseur de code est probablement une bonne méthode pour les projets naissants, mais pas forcément autant pour les gros projets.
Tu ne parles que des "bons cas" dans les deux scénarios. [...] ne dit rien, et le patch stagne. Dans les conflits dont on entend parler où un mainteneur bloque un projet, c'est souvent ce genre de problèmes à la base, où les gens s'accrochent à une notion de qualité qui a l'effet de geler le projet. C'est très facile de tomber dans ce travers là, ça m'est arrivé à moi aussi, et je pense que que c'est important d'en être conscient.
C'est vrai, ça arrive très souvent, surtout quand y a peu de développeurs. Et là aussi GIMP est un parfait exemple car nous sommes trop peu. Je ne crois pas qu'il y ait de vraie solution, et en particulier, je doute que transiger sur la qualité soit vraiment la solution. Comme je le disais, ce serait le meilleur moyen de bousiller le projet en rendant son code non-maintenable à moyen terme. On en accepte 1, puis 2, puis 10, puis 100. Et voilà, la base de code est flinguée.
Le second problème est les problématiques de design d'UI. Beaucoup de patchs bloquent sur les choix UI car les utilisateurs et contributeurs ont tous ce "petit quelque chose qui va rendre GIMP 1000 fois mieux!", disent-ils. Bien sûr, ils ne voient que leur utilisation, et parfois même pas forcément une utilisation habituelle. Genre ils basent leur patch sur leur expérience d'un projet où ils ont dû faire une tâche assez répétitive et ils se sont alors dit que si y avait tel bouton là pour faire ça, ça aurait vachement simplifié leur tâche donc ils font un patch et le défendent corps et âme. Mais je suis même pas sûr qu'une fois ce projet terminé, ils aient jamais besoin d'utiliser ce bouton encore. Et quand bien même, y a des millions d'autres utilisateurs de GIMP.
Le truc, c'est que si on devait accepter tous les patchs pour ajouter des boutons, à ce jour y aurait 1000 boutons dans chaque dock. En fait je trouve qu'y en a déjà trop. Je parle même pas de l'ordre des boutons ou fonctions. C'est simple, on a dû avoir des demandes pour toutes les combinaisons possibles. Si on acceptait chaque fois un patch pour changer l'ordre, GIMP serait totalement schizophrène et changerait l'ordre de ses boutons constamment.
Ce qu'il nous fait, c'est une GUI plus personnalisable, mais forcément ce patch n'est pas aussi simple si on veut le faire bien (c'est d'ailleurs dans mes cartons). ;-)
Tout ça pour dire que même si ce que tu dis est vrai, je ne suis pas sûr que ce soit une mauvaise chose de "s'accrocher à une notion de qualité" et s'y tenir. Mais encore une fois, un projet comme GIMP (ou gcc, et probablement même LLVM, ainsi que tout gros projet avec beaucoup de code et une base d'utilisateur énorme) doit être géré différemment. On ne doit pas s'empêcher d'expérimenter (et on le fait vraiment beaucoup; si t'as l'occasion d'essayer la version de dév, essaie!), mais on ne peut pas non plus faire tout et n'importe quoi.
Encore une fois, je pense donc que ce que tu dis s'appliquera bien mieux à un petit projet qui a tout intérêt à avoir des contributeurs et qui peut se permettre de changer plein de petits trucs très régulièrement.
À ma surprise à l'époque, les contributeurs m'ont demandé d'arrêter: ils n'aiment pas qu'on modifie leurs patchs "derrière eux" parce qu'ils ont vraiment envie d'apprendre comment faire le patch parfait et ils préfèrent donc que je leur explique les changements à faire. Maintenant je ne le fais que très très rarement.
Ah ça m'est jamais arrivé. Mais bon dans mon cas, je ne le fais que soit parce que le contributeur ne répond pas (mais que son patch est suffisamment intéressant pour être intégré moyennant quelques corrections), soit après déjà 3 ou 4 patchs corrigés (mais le contributeur n'a pas compris ou vu tous les problèmes qu'on lui soumettait); donc je pense qu'à ce moment le contributeur est soulagé de ne pas avoir à faire un autre aller-retour revue-patch.
Dans mon cas, j'essaie aussi de le faire aussi rarement que possible.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mainteneurs grincheux
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal LLVM se fait de vieux os ? La recherche pour rester jeune.. Évalué à 7. Dernière modification le 21 décembre 2016 à 18:07.
Bien sûr. Mais comme c'est une histoire de philosophie de maintenance, on rencontre souvent les extrêmes.
C'est marrant (et j'imagine, le hasard) car justement le journal qui te suit parle de cela, mais de l'autre point de vue.
Pieter Hintjens est un développeur récemment décédé et ce serait sa pensée qu'il explique dans des articles:
C'est vraiment à l'inverse de ce qu'on fait dans un logiciel qui va contrôler plus sérieusement les patchs. Même s'il y a aussi un entre-deux possible, ici on voit plus des philosophies opposées. C'est pour ça que je fais ce genre de séparation (même si tu as raison). Ensuite je comprends bien ce point de vue laxiste aussi et je pense qu'il marche mieux pour les plus petits projets (petit notamment en nombre de lignes/fichiers). Pourquoi? Parce qu'un peu de bordel est acceptable dans ce cas. Ça reste lisible. Pour lancer un projet, c'est sûrement idéal même d'être très laxiste sur la revue de patch. Je n'étais pas là à l'époque, mais je suis sûr que ça a dû être le cas au début de GIMP aussi.
De nos jours, GIMP est un projet gigantesque en terme de fichiers, lignes de code, et fonctionnalité. Et pourtant il est globalement extrêmement bien organisé. L'architecture sépare bien les diverses parties du code (le "core" fonctionnel, les actions, la peinture, la gestion de fichier, les opérations graphiques, le GUI... et bien plus de sous-séparations encore). Le style de code est plutôt bien respecté partout (rendant le code très lisible). Etc.
Si on se mettait à accepter un patch qui casse nos diverses règles juste parce qu'il "marche", je pense que ce serait le début de la fin et qu'au bout d'un an, le code ne serait plus aussi maintenable.
C'est pas parfait mais c'est une base de code étonnamment bonne pour un projet de 21 ans. En fait je me rends compte que pas mal de gros projets sur lesquels j'ai contribué ont des bases globalement saines, alors que beaucoup de petits projets sont des bordels sans nom. Cela correspondrait donc à mon intuition comme quoi le laxisme du réviseur de code est probablement une bonne méthode pour les projets naissants, mais pas forcément autant pour les gros projets.
C'est vrai, ça arrive très souvent, surtout quand y a peu de développeurs. Et là aussi GIMP est un parfait exemple car nous sommes trop peu. Je ne crois pas qu'il y ait de vraie solution, et en particulier, je doute que transiger sur la qualité soit vraiment la solution. Comme je le disais, ce serait le meilleur moyen de bousiller le projet en rendant son code non-maintenable à moyen terme. On en accepte 1, puis 2, puis 10, puis 100. Et voilà, la base de code est flinguée.
Le second problème est les problématiques de design d'UI. Beaucoup de patchs bloquent sur les choix UI car les utilisateurs et contributeurs ont tous ce "petit quelque chose qui va rendre GIMP 1000 fois mieux!", disent-ils. Bien sûr, ils ne voient que leur utilisation, et parfois même pas forcément une utilisation habituelle. Genre ils basent leur patch sur leur expérience d'un projet où ils ont dû faire une tâche assez répétitive et ils se sont alors dit que si y avait tel bouton là pour faire ça, ça aurait vachement simplifié leur tâche donc ils font un patch et le défendent corps et âme. Mais je suis même pas sûr qu'une fois ce projet terminé, ils aient jamais besoin d'utiliser ce bouton encore. Et quand bien même, y a des millions d'autres utilisateurs de GIMP.
Le truc, c'est que si on devait accepter tous les patchs pour ajouter des boutons, à ce jour y aurait 1000 boutons dans chaque dock. En fait je trouve qu'y en a déjà trop. Je parle même pas de l'ordre des boutons ou fonctions. C'est simple, on a dû avoir des demandes pour toutes les combinaisons possibles. Si on acceptait chaque fois un patch pour changer l'ordre, GIMP serait totalement schizophrène et changerait l'ordre de ses boutons constamment.
Ce qu'il nous fait, c'est une GUI plus personnalisable, mais forcément ce patch n'est pas aussi simple si on veut le faire bien (c'est d'ailleurs dans mes cartons). ;-)
Tout ça pour dire que même si ce que tu dis est vrai, je ne suis pas sûr que ce soit une mauvaise chose de "s'accrocher à une notion de qualité" et s'y tenir. Mais encore une fois, un projet comme GIMP (ou gcc, et probablement même LLVM, ainsi que tout gros projet avec beaucoup de code et une base d'utilisateur énorme) doit être géré différemment. On ne doit pas s'empêcher d'expérimenter (et on le fait vraiment beaucoup; si t'as l'occasion d'essayer la version de dév, essaie!), mais on ne peut pas non plus faire tout et n'importe quoi.
Encore une fois, je pense donc que ce que tu dis s'appliquera bien mieux à un petit projet qui a tout intérêt à avoir des contributeurs et qui peut se permettre de changer plein de petits trucs très régulièrement.
Ah ça m'est jamais arrivé. Mais bon dans mon cas, je ne le fais que soit parce que le contributeur ne répond pas (mais que son patch est suffisamment intéressant pour être intégré moyennant quelques corrections), soit après déjà 3 ou 4 patchs corrigés (mais le contributeur n'a pas compris ou vu tous les problèmes qu'on lui soumettait); donc je pense qu'à ce moment le contributeur est soulagé de ne pas avoir à faire un autre aller-retour revue-patch.
Dans mon cas, j'essaie aussi de le faire aussi rarement que possible.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]