Depuis plusieurs mois (années ?), je lis vos comptes rendu des nouvelles fonctionnalités, et elles me semblent très intéressantes (bien que je ne fasse plus de photo). Pourquoi attendre pour sortir une version 3.0 finale ?
Déjà parce qu'on était dans le modèle ancien de "release when it's ready", qui explique que la sortie de GIMP 2.8 a aussi mis 4 ans (2008 à 2012), 2.10 a mis 6 ans (2012 à 2018) et 3.0 aura vraisemblablement mis entre 5 et 6 ans (on a démarré en 2018).
Comme les gens le savent, on est en train de changer ce modèle (bon on sort encore les choses "quand elles sont prêtes" mais tout la subtilité est d'arriver à définir différemment "ce qui doit être prêt"), d'ailleurs sur une impulsion de notre part, puisque c'est un changement que j'ai proposé lors du Libre Graphics Meeting de 2014. C'est ainsi que depuis GIMP 2.10.0, on applique cette nouvelle politique de sortie: on sort désormais de nouvelles fonctionnalités même lors des sorties micro maintenant! Tout ce qui est suffisamment aisément backportables sort dans les versions 2.10.x. Je suggère donc de jeter un œil sur le tag "GIMP" sur Linuxfr et de lire les articles de sortie des versions stables pour se rendre compte qu'il y a des nouveautés à chaque fois (et pas juste des corrections de bug).
Pour moi le risque d'attendre trop longtemps est de démotiver les développeurs de n'avoir rien de montrable "officiellement", et de démotiver les utilisateurs attendant trop longtemps les nouvelles fonctionnalités
Donc si ce que tu dis était vrai avant 2018, ce n'est plus le cas depuis (puisque maintenant les développeurs attendent juste quelques mois pour voir leur code utilisé et les utilisateurs pour l'utiliser).
Ensuite comme tout, on peut faire mieux. Mais cela demande rigueur et organisation. Et surtout, cela prend du temps, des années même. On ne change pas une organisation de 28 ans en quelques mois (c'est le meilleur moyen de tout pêter, certains l'apprennent à leurs dépends, par exemple des milliardaires qui s'amusent à acheter des boîtes et les font quasi couler en quelques mois en pensant être des révolutionnaires! 🙄).
Et donc maintenant après la première étape de 2018 avec GIMP 2.10, on passera à une seconde étape avec GIMP 3.0. Je l'explique d'ailleurs dans mon rapport 2022 de janvier 2023 (qui n'a pas été traduit sur Linuxfr):
While this second target is still definitely a big plan in our roadmap, I don’t think that making it again a huge development cycle with dozens of features and taking several years is the wisest thing. This old development model made sense back in the day, but less nowadays in my opinion.
En gros, on arrête de faire de grosses cibles gigantesques. J'ai aussi entièrement réorganisé notre roadmap post-3.0 non plus par versions mais en sous-roadmaps par catégorie de fonctionnalités dont les éléments peuvent être implémentées dans n'importe quelle version. C'est important puisque ça signifie que nous ne sommes plus contraints à de grosses listes de fonctionnalités. Nous avons maintenant un ensemble de directions globales vers lesquelles nous nous dirigeons (notre "vision" pour le futur de GIMP, en gros), c'est tout.
Donc c'est bien ce qu'on fait, on a même déjà commencé depuis plusieurs années; ça prend juste du temps pour faire encore mieux.
Il y a un autre point important: une sortie de version est un évènement très lourd. On rappelle que GIMP est téléchargé des dizaines de milliers de fois par jour. On ne fait pas une nouvelle version comme on va au marché. C'est lourd en responsabilité, mais aussi techniquement, avec du code et des builds à tester à répétition, un flatpak pour x86_64 et ARM64, deux paquets macOS (aussi pour ces deux architectures) et un installeur Windows (qui marche pour x86 32 et 64-bit et possiblement aussi un installeur ARM bientôt), puis une dépêche qui me prend des jours à écrire, etc. Une sortie bien faite en gros, ça peut être des semaines de travail juste pour tous les aspects hors-code (donc tout ce temps en moins pour coder! Plus on fait de sorties, moins vite on peut améliorer GIMP; il faut donc trouver le juste milieu). Imagine une sortie d'une version majeure maintenant, surtout qu'on n'en a pas faite depuis 20 ans.
Ça fait des années que je travaille sur tout l'aspect technique (hors code de GIMP même, j'entends) pour préparer cette sortie. En cumulé, j'ai probablement passé des semaines ou des mois à créer et améliorer nos scripts d'intégration continu, qui permettent aussi d'automatiser le plus possible nos créations de binaires de sortie (le flatpak n'existait pas à l'époque mais les tarballs de source autant que les installeurs Windows ou DMG macOS, avant moi, c'était des binaires opaques que des contributeurs faisaient sur leur machine perso puis envoyaient sur les serveurs; rendre le tout plus transparent fut un de mes gros chantiers et ce fut loin d'être facile avec certains contributeurs — notamment je me souviens d'un qui n'est plus là et qui n'a pas apprécié les premières tentatives d'automatiser la création des paquets macOS). Sans compter tout le travail fait pour améliorer notre checklist de procédure de sortie. Cela existait déjà avant, comme un fichier texte dans le dépôt suivi par juste le mainteneur. J'essaie maintenant d'intégrer davantage les testeurs, les empaqueteurs, etc. En gros d'avoir une sortie avec le moins de heurts possibles, tout en étant aussi plus robuste.
Maintenant spécifiquement pour GIMP 3.0, je pense pouvoir expliquer la durée par quelques points:
Le portage vers GTK+3 est un truc chiant et ennuyeux, donc la plupart des volontaires n'aiment pas y passer trop longtemps. Le portage vers GTK4 a l'air tout aussi chiant. Ils ont même déprécié ou retiré des fonctionnalités ajoutées/changées dans GTK+3! Honnêtement après avoir passé des mois à travailler sur notre port des actions et m'être rendu compte qu'une partie des nouvelles API sont déjà en voie de disparition dans GTK4, ça me déprime plus qu'autre chose. J'aimerais bien que les toolkits aussi fassent les choses plus progressivement. Le problème est que si les dévs de toolkit eux-même ne font que des petits "apps", ils se rendent pas compte du boulot pour un port pour une application un peu complexe.
En dehors de ce fait, si on s'était limité à un port vers GTK+3, on pourrait se dire qu'on aurait pu y passer moins de temps, mais puisque c'est un boulot chiant, ce n'est même pas vrai. Il y aurait simplement eu des "trous" dans le développement. Autant l'employer pour implémenter des trucs cools.
On aurait aussi pu sortir GIMP plus tôt avec un port incomplet (on a une version GTK+3 utilisable depuis quelques années, simplement on avait des centaines voire milliers de warnings) mais d'une, sortir un logiciel avec ces warnings n'est pas une pratique recommandée. Les warnings de compilation sont censés montrer des problèmes potentiels, c'est à dire des bugs probables. Or là on était noyés de warnings de dépréciation de code nous empêchant de voir les vrais bugs. Est-ce une bonne idée de sortir une version dite "stable" dans cet état?
De deux, alors que certains (ceux qui traînent sur les forums technologiques, genre ici) sont à fond sur les nouveautés, énormément de gens sont en fait à fond sur la stabilité d'interface (le xkcd de rigueur?). Même si certaines choses vont immanquablement changer, on fait donc tout un travail pour s'assurer que ça ne change pas trop. C'était vrai notamment pour les actions. Je devais être sûr que je puisse sortir quelque chose avec le minimum de "sensation de changement". En gros, notre système d'actions/raccourcis est radicalement différent mais il a l'air identique (c'en est presque le plus frustrant, mais c'est important). C'est là toute la subtilité. Et si je précipite la sortie puis me rend compte après coup que je n'aurais pas été capable de cette prouesse technique, ça aurait été très embêtant et il aurait fallu changer les plans. Le problème, c'est que pour être sûr à 100% qu'il n'y a pas de problème, le mieux est de finir.
Il y a la stabilité de tout ce qui ne se voit pas qui est important, tels les protocoles internes et fichiers de configuration. Typiquement avec les actions, le fichier de configuration des raccourcis a changé. Or on assure une migration de ces fichiers entre versions mineures, pas entre version micro. Il aurait fallu rajouter une nouvelle infrastructure pour cela (heureusement tout de même, j'ai commencé à rajouter quelques pré-étapes pour permettre cela un jour).
Wayland aussi nous a facilement fait perdre des mois. C'est le futur parce qu'on n'a pas le choix et techniquement, c'est sûrement plus propre (autant que les micro-kernels sont plus propres que les kernels monolithiques en théorie; pourtant on sait qui de Hurd ou Linux a pris le devant de la scène dans l'histoire de l'informatique!), mais ça n'en reste pas moins un truc encore pas fini et plein de problèmes, et pourtant mis en production, avec lequel donc on est forcé de composer.
L'API enfin est un énorme bloqueur. Nous sommes extrêmement à cheval sur sa stabilité et on ne s'est autorisé que cette version pour casser la stabilité dans les ~20 dernières années. Donc on doit le faire bien. La stabilité des interfaces font partie de ces choses sur lesquelles les gens se plaignent lorsque c'est mal fait, mais personne ne s'en rend compte lorsque c'est bien fait (même si on n'est pas parfait). On essaie d'être de la seconde catégorie. Donc personne ne remarque le travail phénoménal assuré derrière le rideau pour assurer la stabilité d'API. Au contraire, on pourrait juste presser la sortie, bâcler l'API puis se permettre de la casser tous les 4 matins ensuite. Certains font ça. Encore y a quelques jours, avec la grosse mise-à-jour récente de Thunderbird, j'ai des plug-ins qui ont cassé. Régulièrement j'ai eu des plug-ins qui ont cassé dans Firefox (moins maintenant ceci dit). Bon encore ce sont pas les pires élèves.
Mes plug-ins GNOME survivent rarement plus d'une mise-à-jour. Là par contre, c'est un mauvais élève (mais il paraît que c'est fait exprès parce que le projet ne veut pas se bloquer en assurant une stabilité d'API, et c'est ça le plus dommage).
On essaie d'éviter ça (même s'il faut "jamais dire jamais", comme on dit!). On se permet un cassage avec GIMP 3 en 20 ans (et même là je me suis plus d'une fois demandé si on aurait pas pu faire mieux), et j'espère qu'on va pas en avoir beaucoup plus. Donc si on n'a que cette chance pour casser l'API, autant le faire bien.
De manière générale, nous sommes un projet un peu à l'ancienne dans les philosophies de développement, mais aussi dans la définition de ce qu'est du bon développement. Notamment vous remarquerez que les mots "stable" ou "stabilité" sont répétés beaucoup dans ce seul commentaire. C'est en effet un concept important pour nous sur plein de choses. J'ai aussi l'impression que les mainteneurs de GIMP sont une longue lignée de perfectionnistes. Saviez-vous qu'on est censé pouvoir ouvrir un fichier XCF de 1997 avec son rendu de l'époque? Nous en sommes à la version 18 de XCF avec énormément de nouveautés dans le format, mais on peut encore ouvrir les fichiers d'il y a 26 ans! Peu de projets (même libres! Quant aux logiciels propriétaires, n'en parlons même pas tellement ils ont de casseroles sur ce sujet) peuvent s'enorgueillir de cela, et même tout simplement de placer ce niveau de rétrocompatibilité dans leurs checklists lors des changements de format.
Et donc voilà, tout cela explique pourquoi cela prend du temps. Ensuite on peut tout de même améliorer la fréquence des sorties sans pour autant perdre en qualité, mais c'est alors surtout une réorganisation en profondeur qui ne peut que prendre encore plus de temps si on ne veut pas tout casser et si on veut travailler en bonne entente en communauté. Et c'est bien ce que nous faisons depuis plusieurs années.
Merci pour tous ces chouettes articles en tout cas. Et GIMP est un logiciel génial, belle vitrine du logiciel libre !
Merci! 😄 (et merci à Matthieu pour sa traduction!)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pourquoi attendre pour publier une version 3.0 ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Sortie de GIMP 2.99.16 : édition Wilber Week 2023 !. Évalué à 10.
Déjà parce qu'on était dans le modèle ancien de "release when it's ready", qui explique que la sortie de GIMP 2.8 a aussi mis 4 ans (2008 à 2012), 2.10 a mis 6 ans (2012 à 2018) et 3.0 aura vraisemblablement mis entre 5 et 6 ans (on a démarré en 2018).
Comme les gens le savent, on est en train de changer ce modèle (bon on sort encore les choses "quand elles sont prêtes" mais tout la subtilité est d'arriver à définir différemment "ce qui doit être prêt"), d'ailleurs sur une impulsion de notre part, puisque c'est un changement que j'ai proposé lors du Libre Graphics Meeting de 2014. C'est ainsi que depuis GIMP 2.10.0, on applique cette nouvelle politique de sortie: on sort désormais de nouvelles fonctionnalités même lors des sorties micro maintenant! Tout ce qui est suffisamment aisément backportables sort dans les versions 2.10.x. Je suggère donc de jeter un œil sur le tag "GIMP" sur Linuxfr et de lire les articles de sortie des versions stables pour se rendre compte qu'il y a des nouveautés à chaque fois (et pas juste des corrections de bug).
Donc si ce que tu dis était vrai avant 2018, ce n'est plus le cas depuis (puisque maintenant les développeurs attendent juste quelques mois pour voir leur code utilisé et les utilisateurs pour l'utiliser).
Ensuite comme tout, on peut faire mieux. Mais cela demande rigueur et organisation. Et surtout, cela prend du temps, des années même. On ne change pas une organisation de 28 ans en quelques mois (c'est le meilleur moyen de tout pêter, certains l'apprennent à leurs dépends, par exemple des milliardaires qui s'amusent à acheter des boîtes et les font quasi couler en quelques mois en pensant être des révolutionnaires! 🙄).
Et donc maintenant après la première étape de 2018 avec GIMP 2.10, on passera à une seconde étape avec GIMP 3.0. Je l'explique d'ailleurs dans mon rapport 2022 de janvier 2023 (qui n'a pas été traduit sur Linuxfr):
En gros, on arrête de faire de grosses cibles gigantesques. J'ai aussi entièrement réorganisé notre roadmap post-3.0 non plus par versions mais en sous-roadmaps par catégorie de fonctionnalités dont les éléments peuvent être implémentées dans n'importe quelle version. C'est important puisque ça signifie que nous ne sommes plus contraints à de grosses listes de fonctionnalités. Nous avons maintenant un ensemble de directions globales vers lesquelles nous nous dirigeons (notre "vision" pour le futur de GIMP, en gros), c'est tout.
Donc c'est bien ce qu'on fait, on a même déjà commencé depuis plusieurs années; ça prend juste du temps pour faire encore mieux.
Il y a un autre point important: une sortie de version est un évènement très lourd. On rappelle que GIMP est téléchargé des dizaines de milliers de fois par jour. On ne fait pas une nouvelle version comme on va au marché. C'est lourd en responsabilité, mais aussi techniquement, avec du code et des builds à tester à répétition, un flatpak pour x86_64 et ARM64, deux paquets macOS (aussi pour ces deux architectures) et un installeur Windows (qui marche pour x86 32 et 64-bit et possiblement aussi un installeur ARM bientôt), puis une dépêche qui me prend des jours à écrire, etc. Une sortie bien faite en gros, ça peut être des semaines de travail juste pour tous les aspects hors-code (donc tout ce temps en moins pour coder! Plus on fait de sorties, moins vite on peut améliorer GIMP; il faut donc trouver le juste milieu). Imagine une sortie d'une version majeure maintenant, surtout qu'on n'en a pas faite depuis 20 ans.
Ça fait des années que je travaille sur tout l'aspect technique (hors code de GIMP même, j'entends) pour préparer cette sortie. En cumulé, j'ai probablement passé des semaines ou des mois à créer et améliorer nos scripts d'intégration continu, qui permettent aussi d'automatiser le plus possible nos créations de binaires de sortie (le flatpak n'existait pas à l'époque mais les tarballs de source autant que les installeurs Windows ou DMG macOS, avant moi, c'était des binaires opaques que des contributeurs faisaient sur leur machine perso puis envoyaient sur les serveurs; rendre le tout plus transparent fut un de mes gros chantiers et ce fut loin d'être facile avec certains contributeurs — notamment je me souviens d'un qui n'est plus là et qui n'a pas apprécié les premières tentatives d'automatiser la création des paquets macOS). Sans compter tout le travail fait pour améliorer notre checklist de procédure de sortie. Cela existait déjà avant, comme un fichier texte dans le dépôt suivi par juste le mainteneur. J'essaie maintenant d'intégrer davantage les testeurs, les empaqueteurs, etc. En gros d'avoir une sortie avec le moins de heurts possibles, tout en étant aussi plus robuste.
Maintenant spécifiquement pour GIMP 3.0, je pense pouvoir expliquer la durée par quelques points:
On essaie d'éviter ça (même s'il faut "jamais dire jamais", comme on dit!). On se permet un cassage avec GIMP 3 en 20 ans (et même là je me suis plus d'une fois demandé si on aurait pas pu faire mieux), et j'espère qu'on va pas en avoir beaucoup plus. Donc si on n'a que cette chance pour casser l'API, autant le faire bien.
De manière générale, nous sommes un projet un peu à l'ancienne dans les philosophies de développement, mais aussi dans la définition de ce qu'est du bon développement. Notamment vous remarquerez que les mots "stable" ou "stabilité" sont répétés beaucoup dans ce seul commentaire. C'est en effet un concept important pour nous sur plein de choses. J'ai aussi l'impression que les mainteneurs de GIMP sont une longue lignée de perfectionnistes. Saviez-vous qu'on est censé pouvoir ouvrir un fichier XCF de 1997 avec son rendu de l'époque? Nous en sommes à la version 18 de XCF avec énormément de nouveautés dans le format, mais on peut encore ouvrir les fichiers d'il y a 26 ans! Peu de projets (même libres! Quant aux logiciels propriétaires, n'en parlons même pas tellement ils ont de casseroles sur ce sujet) peuvent s'enorgueillir de cela, et même tout simplement de placer ce niveau de rétrocompatibilité dans leurs checklists lors des changements de format.
Et donc voilà, tout cela explique pourquoi cela prend du temps. Ensuite on peut tout de même améliorer la fréquence des sorties sans pour autant perdre en qualité, mais c'est alors surtout une réorganisation en profondeur qui ne peut que prendre encore plus de temps si on ne veut pas tout casser et si on veut travailler en bonne entente en communauté. Et c'est bien ce que nous faisons depuis plusieurs années.
Merci! 😄 (et merci à Matthieu pour sa traduction!)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]