Ne pensez-vous pas que la roadmap 2.10 n'est été trop importante étant donné le nombre limités de contributeurs actifs sur le projet ?
Je crois que cette phrase de mon article répond à ta question:
GIMP a été entièrement développé en bénévolat jusqu'à très récemment.
En gros, une entreprise (ou autre entité unique qui gère un logiciel avec des employés) va avoir sa roadmap interne et elle priorise plus facilement certains trucs. Ce n'est pas forcément mieux pour tout. Cela peut d'ailleurs provoquer des conflits avec la communauté quand certains aspects sont trop strictement contrôlés par cette entité, voire quand des refus (ou non-intégration sans refus clair) de fonctionnalités se produisent sans raison claire (par exemple, le rapport de bug de la fonctionnalité WebP dont je donne un lien plus haut vers le bugzilla de Mozilla est à un moment complètement parti en vrille car il y a des patchs depuis plus d'un an et beaucoup de gens attendent que Mozilla finissent la revue et l'intègre; au final le bug est passé lecture seule pour stopper la montée en troll).
Ils ont des employés, ils ont une roadmap probablement assez directive, ils s'y tiennent, et parfois s'ils ont le temps, ils se permettent de regarder un peu ce que fait la communauté.
Dans le cas de GIMP, c'est complètement différent. Pourquoi? Parce qu'y a aucun manager pour dire "c'est la roadmap, c'est comme ça, vous obéissez", et aucun employé pour suivre cette roadmap (qu'il peut discuter, mais au final s'il veut garder son job et que ses arguments sont refusés, il suivra). La "roadmap" de GIMP est donc totalement fluide et cible mouvante. Si tu préfères, on peut presque dire qu'il n'y a pas vraiment de roadmap (dit-il en donnant un lien). Elle est "presque" faite après coup. Ou plutôt puisqu'on se base quasi-essentiellement sur le volontariat, elle dépend des contributeurs du moment. Si y a un contributeur très impliqué qui un jour décide que telle fonctionnalité est sa priorité, alors cela rentre plus ou moins naturellement dans notre roadmap. Bon sauf si la dite-fonctionnalité est totalement tordue et que les autres dévs la refusent... en particulier le mainteneur qui aura le dernier mot (il y a quand même une "vision" du logiciel, disons qu'elle est plus fluide que dans un logiciel commercial).
Pour 2.10, le seul vrai item de la roadmap initiale selon moi, le fil directeur, c'était — je pense — le port de GEGL. Quasiment tout le reste, c'était des choses qui sont simplement arrivées naturellement pendant ce port car des gens (les dévs core ou des contributeurs externes) ont proposés ces améliorations. Quasi rien de ce que vous lisez dans cette news n'était initialement prévu (du moins, pas noir sur blanc comme un plan clair et net).
Le port GEGL en particulier a pris beaucoup de temps car c'est un sujet compliqué, et comme tu le dis, y a peu de développeurs. Lors de mes premiers builds (fin 2012, quand j'ai commencé à contribuer avec quelques patchs mineurs), le gros du port vers GEGL avait déjà été fait, mais GIMP 2.9 était tout simplement inutilisable au quotidien. Les opérations et surtout la peinture sur canevas était incroyablement lentes (tu faisais un trait puis tu allais faire un café le temps que ça apparaisse, ou presque ;p). Les choses se sont progressivement améliorées mais cela a pris du temps. Pendant ce temps là, quand les gens proposaient des patchs pour des nouvelles fonctionnalités super cools, ben le projet allait pas les refuser (sinon les gens proposent plus de patchs et y a pas de nouveaux dévs!).
En gros, tu ne peux pas refuser des fonctionnalités en demandant aux gens de bosser sur autre chose. Si un gars nous propose un patch géniale sur une fonctionnalité révolutionnaire, tu ne vas pas lui dire "ah c'est pas dans notre roadmap, désolé. Par contre, on remarque que tu es un développeur doué. Tu voudrais pas plutôt coder sur GEGL ou le port de GEGL dans GIMP?". Tu fais ça, le gars se barre (en gueulant ou silencieusement suivant les tempéraments), tu entends plus parler de lui et tu viens de tirer un trait sur ta fonctionnalité révolutionnaire.
Par contre, si tu te dis "c'est vraiment trop cool, faut qu'on intègre ça", ben tu te prends un peu de temps pour faire de la revue, commenter le code, demander des corrections, puis l'intégrer, probablement rajouter du code autour pour rendre le truc encore plus génial, etc. Au final, oui tu as utilisé du temps (qui peut-être aurait pu être utilisé pour le port de GEGL... ou pas! On rappelle: volontariat, les gens bossent sur ce qu'ils veulent), ça n'a pas fait avancer GEGL, mais tu as une méga fonctionnalité à la fin. Et le nouveau contributeur, peut-être même qu'il va rester dans le coin et proposer d'autres fonctionnalités géniales. Ou pas. Peut-être qu'il va vouloir aider au port GEGL. Ou pas. Peut-être qu'il va se barrer et on va jamais le revoir. C'est 90% des cas mais ça reste mieux que refuser la fonctionnalité et le gars se barre dans 100% des cas, et en plus on perd une fonctionnalité.
Et surtout, les nouvelles fonctionnalités n'impactent en rien (ou rarement) le port vers GEGL. Donc les refuser sous prétexte que ce n'est pas dans la roadmap n'a aucun intérêt. Refuser une fonctionnalité super cool car GEGL est lent, ou que d'autres parties de GIMP ne sont pas encore portées n'améliore pas ces aspects problématiques (ça n'empire pas non plus. En gros, rien à voir, fils unique, quoi...). Par contre bien sûr, on demande à ce que les nouvelles fonctionnalités soient bien basées sur GEGL (si pertinent). On veut pas intégrer une fonctionnalité basée sur 2.8 et devoir la porter après coup. Là oui, ce serait aller à reculons.
Je ne vais pas expliquer les avantages d'avoir des releases plus fréquentes je pense ne rien vous apprendre mais j'ai du mal à comprendre
Je suppose que tu parles de sorties avec de nouvelles fonctionnalités. Non parce que sinon, GIMP a des sorties tous les 3 à 6 mois (on est à la version 2.8.22, ça fait 12 sorties depuis 2012, c'est plutôt fréquent!). ;-)
Donc oui, je suis d'accord avec toi; notre problème est qu'on fait partie de ces logiciels de la vieille époque qui ont des majeures, mineurs, avec une sémantique des versions, et en particulier: pas de nouvelles fonctionnalités dans une mineure. Depuis les logiques de sortie ont changés dans beaucoup de logiciels jusqu'au point de même faire sauter les logiques de majeures/mineures tout court (beaucoup de logiciels incrémentent simplement à chaque sortie).
On était bloqué par le port de GEGL. Comme je l'ai dit, pendant plusieurs années, c'était trop lent, ou trop imparfait, etc. Mais on est bien conscient du problème et on a décider de faire évoluer notre mode de sortie après la 2.10 car nous entamerons alors un nouveau port qui peut être à nouveau long: le port vers GTK+3.
Nous avons donc décidé et annoncé officiellement en début d'années que nous assouplirons la règle "pas de nouvelle fonctionnalité dans des sorties mineures" après GIMP 2.10.
C'est une évolution que je pousse depuis 2014 (voir par exemple ce compte-rendu de LGM, section "Les réunions GIMP"), et j'ai finalement réussi à faire progresser cela jusqu'à une officialisation.
Donc oui, GIMP aura des sorties de fonctionnalités plus régulières à partir de 2.10. Il y a de fortes chances que nous assouplissons encore plus la logique des versions après GIMP 3. En tous cas, c'est personnellement dans ce sens là que je pousse.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: roadmap trop importante ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 10. Dernière modification le 15 décembre 2017 à 02:24.
Je crois que cette phrase de mon article répond à ta question:
En gros, une entreprise (ou autre entité unique qui gère un logiciel avec des employés) va avoir sa roadmap interne et elle priorise plus facilement certains trucs. Ce n'est pas forcément mieux pour tout. Cela peut d'ailleurs provoquer des conflits avec la communauté quand certains aspects sont trop strictement contrôlés par cette entité, voire quand des refus (ou non-intégration sans refus clair) de fonctionnalités se produisent sans raison claire (par exemple, le rapport de bug de la fonctionnalité WebP dont je donne un lien plus haut vers le bugzilla de Mozilla est à un moment complètement parti en vrille car il y a des patchs depuis plus d'un an et beaucoup de gens attendent que Mozilla finissent la revue et l'intègre; au final le bug est passé lecture seule pour stopper la montée en troll).
Ils ont des employés, ils ont une roadmap probablement assez directive, ils s'y tiennent, et parfois s'ils ont le temps, ils se permettent de regarder un peu ce que fait la communauté.
Dans le cas de GIMP, c'est complètement différent. Pourquoi? Parce qu'y a aucun manager pour dire "c'est la roadmap, c'est comme ça, vous obéissez", et aucun employé pour suivre cette roadmap (qu'il peut discuter, mais au final s'il veut garder son job et que ses arguments sont refusés, il suivra). La "roadmap" de GIMP est donc totalement fluide et cible mouvante. Si tu préfères, on peut presque dire qu'il n'y a pas vraiment de roadmap (dit-il en donnant un lien). Elle est "presque" faite après coup. Ou plutôt puisqu'on se base quasi-essentiellement sur le volontariat, elle dépend des contributeurs du moment. Si y a un contributeur très impliqué qui un jour décide que telle fonctionnalité est sa priorité, alors cela rentre plus ou moins naturellement dans notre roadmap. Bon sauf si la dite-fonctionnalité est totalement tordue et que les autres dévs la refusent... en particulier le mainteneur qui aura le dernier mot (il y a quand même une "vision" du logiciel, disons qu'elle est plus fluide que dans un logiciel commercial).
Pour 2.10, le seul vrai item de la roadmap initiale selon moi, le fil directeur, c'était — je pense — le port de GEGL. Quasiment tout le reste, c'était des choses qui sont simplement arrivées naturellement pendant ce port car des gens (les dévs core ou des contributeurs externes) ont proposés ces améliorations. Quasi rien de ce que vous lisez dans cette news n'était initialement prévu (du moins, pas noir sur blanc comme un plan clair et net).
Le port GEGL en particulier a pris beaucoup de temps car c'est un sujet compliqué, et comme tu le dis, y a peu de développeurs. Lors de mes premiers builds (fin 2012, quand j'ai commencé à contribuer avec quelques patchs mineurs), le gros du port vers GEGL avait déjà été fait, mais GIMP 2.9 était tout simplement inutilisable au quotidien. Les opérations et surtout la peinture sur canevas était incroyablement lentes (tu faisais un trait puis tu allais faire un café le temps que ça apparaisse, ou presque ;p). Les choses se sont progressivement améliorées mais cela a pris du temps. Pendant ce temps là, quand les gens proposaient des patchs pour des nouvelles fonctionnalités super cools, ben le projet allait pas les refuser (sinon les gens proposent plus de patchs et y a pas de nouveaux dévs!).
En gros, tu ne peux pas refuser des fonctionnalités en demandant aux gens de bosser sur autre chose. Si un gars nous propose un patch géniale sur une fonctionnalité révolutionnaire, tu ne vas pas lui dire "ah c'est pas dans notre roadmap, désolé. Par contre, on remarque que tu es un développeur doué. Tu voudrais pas plutôt coder sur GEGL ou le port de GEGL dans GIMP?". Tu fais ça, le gars se barre (en gueulant ou silencieusement suivant les tempéraments), tu entends plus parler de lui et tu viens de tirer un trait sur ta fonctionnalité révolutionnaire.
Par contre, si tu te dis "c'est vraiment trop cool, faut qu'on intègre ça", ben tu te prends un peu de temps pour faire de la revue, commenter le code, demander des corrections, puis l'intégrer, probablement rajouter du code autour pour rendre le truc encore plus génial, etc. Au final, oui tu as utilisé du temps (qui peut-être aurait pu être utilisé pour le port de GEGL... ou pas! On rappelle: volontariat, les gens bossent sur ce qu'ils veulent), ça n'a pas fait avancer GEGL, mais tu as une méga fonctionnalité à la fin. Et le nouveau contributeur, peut-être même qu'il va rester dans le coin et proposer d'autres fonctionnalités géniales. Ou pas. Peut-être qu'il va vouloir aider au port GEGL. Ou pas. Peut-être qu'il va se barrer et on va jamais le revoir. C'est 90% des cas mais ça reste mieux que refuser la fonctionnalité et le gars se barre dans 100% des cas, et en plus on perd une fonctionnalité.
Et surtout, les nouvelles fonctionnalités n'impactent en rien (ou rarement) le port vers GEGL. Donc les refuser sous prétexte que ce n'est pas dans la roadmap n'a aucun intérêt. Refuser une fonctionnalité super cool car GEGL est lent, ou que d'autres parties de GIMP ne sont pas encore portées n'améliore pas ces aspects problématiques (ça n'empire pas non plus. En gros, rien à voir, fils unique, quoi...). Par contre bien sûr, on demande à ce que les nouvelles fonctionnalités soient bien basées sur GEGL (si pertinent). On veut pas intégrer une fonctionnalité basée sur 2.8 et devoir la porter après coup. Là oui, ce serait aller à reculons.
Je suppose que tu parles de sorties avec de nouvelles fonctionnalités. Non parce que sinon, GIMP a des sorties tous les 3 à 6 mois (on est à la version 2.8.22, ça fait 12 sorties depuis 2012, c'est plutôt fréquent!). ;-)
Donc oui, je suis d'accord avec toi; notre problème est qu'on fait partie de ces logiciels de la vieille époque qui ont des majeures, mineurs, avec une sémantique des versions, et en particulier: pas de nouvelles fonctionnalités dans une mineure. Depuis les logiques de sortie ont changés dans beaucoup de logiciels jusqu'au point de même faire sauter les logiques de majeures/mineures tout court (beaucoup de logiciels incrémentent simplement à chaque sortie).
On était bloqué par le port de GEGL. Comme je l'ai dit, pendant plusieurs années, c'était trop lent, ou trop imparfait, etc. Mais on est bien conscient du problème et on a décider de faire évoluer notre mode de sortie après la 2.10 car nous entamerons alors un nouveau port qui peut être à nouveau long: le port vers GTK+3.
Nous avons donc décidé et annoncé officiellement en début d'années que nous assouplirons la règle "pas de nouvelle fonctionnalité dans des sorties mineures" après GIMP 2.10.
C'est une évolution que je pousse depuis 2014 (voir par exemple ce compte-rendu de LGM, section "Les réunions GIMP"), et j'ai finalement réussi à faire progresser cela jusqu'à une officialisation.
Donc oui, GIMP aura des sorties de fonctionnalités plus régulières à partir de 2.10. Il y a de fortes chances que nous assouplissons encore plus la logique des versions après GIMP 3. En tous cas, c'est personnellement dans ce sens là que je pousse.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]