Hmm... Je ne vois pas du tout par quelle logique tu es passé de mon commentaire au tien.
Si à partir d'une certain taille critique, cela devient trop risqué de le bouger
J'imagine que sur ce point, tu fais référence à ce que j'ai dit y a plusieurs commentaires sur la revue stricte. Mais ce n'était pas le sens. "Revue stricte" ne signifie pas "on ne bouge pas". Non un projet avec revue stricte, quand il bouge, il met un point d'honneur à le faire bien. Bien souvent, "faire bien" veut cependant dire "prendre son temps", pas accepter des patchs à la va-vite parce qu'ils "marchent" et tant pis pour l'archi, les règles de code et pour la réflexion sur une meilleure UI et sur l'expérience utilisateur en général !
Est-ce que ça ne veut pas dire que tout gros projet est destiné à être forké ?
"Destiné", je ne sais pas mais l'histoire montre que c'est courant, oui. GIMP a eu au moins 2 forks qui ont fait parlé d'eux. Ensuite les forks sont-ils souhaitables? Parfois oui bien sûr mais si la raison est essentiellement "ils sont chiants à prendre du temps et à vouloir vérifier mon code", je trouve cela dommage. Des 2 forks de GIMP, l'un (GIMP Painter) a des fonctionnalités qu'on voudrait vraiment avoir, on a manifesté notre intérêt, discuté avec le dèv... le problème ? Alors que la 2.8 était sortie, il développait sur des tarballs de la 2.6. De nos jours, il développe sur la branche 2.8 alors que le core a énormément évolué avec l'intégration de GEGL pour la 2.10. En gros il ne semble pas intéressé par notre processus de développement et fait tout à sa sauce. Personnellement je trouve que c'est très dommage et une raison de forker un peu triste. On veut de ses innovations, mais bien entendu elles ne valent pas un reset de tout notre code depuis 2.8! En fait, je lui ai redemandé récemment s'il ne veut pas travailler sur notre branche master et j'ai l'impression qu'il se fait beaucoup d'idées et qu'il s'imagine nos pensées. Quand il dit par exemple qu'il pense que la core team et lui ont des visions du design d'UI différente... je me demande vraiment d'où il peut tirer cela. Déjà même si on parle souvent de "core team" pour simplifier, il n'y a pas une pensée similaire en notre sein. On est surtout un groupe d'individuels. Parfois on a des idées similaires, parfois non, puis on discute, on argumente, parfois on change d'avis...
En plus je crois pas du tout qu'on bloquerait l'idée d'une toolbar horizontale (au contraire, j'y pense même très régulièrement et j'ai pas eu besoin de connaître GIMP-painter pour y penser), ce qu'il semble dire, etc. Quand il dit qu'avec le "succès" de GIMP painter, ça permettra aux dévs de GIMP de se rendre compte des vrais besoins des utilisateurs et aussi ça nous montrera comment implémenter ces fonctionnalités, je pense que ce développeur se fait beaucoup d'illusions sur son travail. Je pense qu'il est un dév très compétent et avec de bonnes idées, mais comme tant d'autres le sont. Il serait un très bon ajout à notre équipe pour faire évoluer GIMP plus vite et mieux (surtout s'il bénéficie de revue de code! Mais il semble ne pas vouloir subir cela); mais seul de son côté, non il n'est pas notre "modèle" à suivre. Et non on n'a pas le temps de regarder son code, surtout si celui-ci se base sur une branche totalement obsolète (vieille de très nombreuses années)!
Dans ce cas, pourquoi donc appeler au fork ici par exemple? C'est pour moi un exemple typique de gâchis de ressources de qualité. :-/
Ensuite, oui y a eu des cas où le fork a été très bénéficiaire (libreoffice vient à l'esprit immédiatement). Mais le fork est un outil qui a un poids et un prix conséquents. Il faut bien peser le pour et le contre avant de s'y lancer.
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é à 5.
Hmm... Je ne vois pas du tout par quelle logique tu es passé de mon commentaire au tien.
J'imagine que sur ce point, tu fais référence à ce que j'ai dit y a plusieurs commentaires sur la revue stricte. Mais ce n'était pas le sens. "Revue stricte" ne signifie pas "on ne bouge pas". Non un projet avec revue stricte, quand il bouge, il met un point d'honneur à le faire bien. Bien souvent, "faire bien" veut cependant dire "prendre son temps", pas accepter des patchs à la va-vite parce qu'ils "marchent" et tant pis pour l'archi, les règles de code et pour la réflexion sur une meilleure UI et sur l'expérience utilisateur en général !
"Destiné", je ne sais pas mais l'histoire montre que c'est courant, oui. GIMP a eu au moins 2 forks qui ont fait parlé d'eux. Ensuite les forks sont-ils souhaitables? Parfois oui bien sûr mais si la raison est essentiellement "ils sont chiants à prendre du temps et à vouloir vérifier mon code", je trouve cela dommage. Des 2 forks de GIMP, l'un (GIMP Painter) a des fonctionnalités qu'on voudrait vraiment avoir, on a manifesté notre intérêt, discuté avec le dèv... le problème ? Alors que la 2.8 était sortie, il développait sur des tarballs de la 2.6. De nos jours, il développe sur la branche 2.8 alors que le core a énormément évolué avec l'intégration de GEGL pour la 2.10. En gros il ne semble pas intéressé par notre processus de développement et fait tout à sa sauce. Personnellement je trouve que c'est très dommage et une raison de forker un peu triste. On veut de ses innovations, mais bien entendu elles ne valent pas un reset de tout notre code depuis 2.8! En fait, je lui ai redemandé récemment s'il ne veut pas travailler sur notre branche master et j'ai l'impression qu'il se fait beaucoup d'idées et qu'il s'imagine nos pensées. Quand il dit par exemple qu'il pense que la core team et lui ont des visions du design d'UI différente... je me demande vraiment d'où il peut tirer cela. Déjà même si on parle souvent de "core team" pour simplifier, il n'y a pas une pensée similaire en notre sein. On est surtout un groupe d'individuels. Parfois on a des idées similaires, parfois non, puis on discute, on argumente, parfois on change d'avis...
En plus je crois pas du tout qu'on bloquerait l'idée d'une toolbar horizontale (au contraire, j'y pense même très régulièrement et j'ai pas eu besoin de connaître GIMP-painter pour y penser), ce qu'il semble dire, etc. Quand il dit qu'avec le "succès" de GIMP painter, ça permettra aux dévs de GIMP de se rendre compte des vrais besoins des utilisateurs et aussi ça nous montrera comment implémenter ces fonctionnalités, je pense que ce développeur se fait beaucoup d'illusions sur son travail. Je pense qu'il est un dév très compétent et avec de bonnes idées, mais comme tant d'autres le sont. Il serait un très bon ajout à notre équipe pour faire évoluer GIMP plus vite et mieux (surtout s'il bénéficie de revue de code! Mais il semble ne pas vouloir subir cela); mais seul de son côté, non il n'est pas notre "modèle" à suivre. Et non on n'a pas le temps de regarder son code, surtout si celui-ci se base sur une branche totalement obsolète (vieille de très nombreuses années)!
Dans ce cas, pourquoi donc appeler au fork ici par exemple? C'est pour moi un exemple typique de gâchis de ressources de qualité. :-/
Ensuite, oui y a eu des cas où le fork a été très bénéficiaire (libreoffice vient à l'esprit immédiatement). Mais le fork est un outil qui a un poids et un prix conséquents. Il faut bien peser le pour et le contre avant de s'y lancer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]