Déjà un peu d'explication du problème pour bien comprendre. Windows cherche les DLLs dans cet ordre:
Le répertoire où se trouve le binaire
le répertoire courant
les divers répertoires système
enfin les répertoires listés dans le PATH.
Pour le binaire principal gimp-2-10, c'est facile car il suffit de mettre toutes nos DLLs dans le même répertoire $PREFIX/bin/. Elles seront toujours trouvées en premier.
Le problème est pour les plug-ins qui sont dans $PREFIX/lib/gimp/2.0/plug-ins/ et lorsque ces plug-ins souhaitent utiliser certaines des bibliothèques livrées avec GIMP (qui sont donc dans $PREFIX/bin/).
On pourrait simplement mettre les librairies à côté de chaque plug-in, mais cela signifierait dupliquer les bibliothèques un certain nombre de fois. Et en plus ça ne permettrait plus aux plug-ins tiers de profiter des biblios livrées. Donc ce n'est pas acceptable.
À la base, on rajoutait donc $PREFIX/bin au début du PATH (qui est spécifié dans un script de lancement). Mais si jamais une application installe une DLL (que nous utilisons, mais dans une version incompatible) dans un répertoire système, alors cette DLL est trouvée avant et les ennuis commencent.
Une autre solution à laquelle je pensais est de jouer avec le répertoire courant (le faire pointer sur $PREFIX/bin) mais il se trouve que si SafeDllSearchMode est activé (apparemment une valeur de la base de registre), le répertoire courant est soudainement cherché après les répertoires système aussi! Donc ça marcherait plus (enfin surtout ça dépendrait de la configuration de l'OS).
La solution est donc d'utiliser SetDllDirectoryW() pour donner la priorité à $PREFIX/bin, et pour être précis le mettre entre le répertoire du binaire (permettant aux plug-ins de bypasser nos biblios au besoin) et les répertoires système. C'est donc une solution au niveau du code.
Un cas supplémentaire que nous avons corrigé dans 2.10.6 fut les plug-ins 32-bit lancé dans un environnement 64-bit. Dans ce cas, on doit leur donner un répertoire différent avec des versions 32-bit de nos bibliothèques (on le met dans $PREFIX/32/bin par défaut, mais j'ai mis un flag pour changer ce répertoire à la compilation). Je détecte donc le bitness d'un plug-in avant de le lancer et lui assigne le bon répertoire de bibliothèques avec SetDllDirectoryW().
Un nouveau cas dont j'ai récemment pris connaissance (et pas encore corrigé) est les plug-ins scripts lancés par un interpréteur 32-bit sur environnement 64-bit (si le script utilise des bibliothèques compilées). Dans ce cas, on devra détecter le bitness de l'interpréteur.
Par exemple notre installeur embarque seulement Python en 32-bit (je ne suis pas sûr pourquoi). Donc des scripts python un peu complexe qui utilise des biblios C risquent de ne pas fonctionner.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Dans votre article, si je veux vous soutenir GIMP c'est pour des projets tierces (la marmotte, tout ça…).
Ce projet tiers est ce qui permet de contribuer à GIMP et a fait de moi l'un des plus gros développeurs de GIMP ces dernières années (même le plus gros selon le décompte).
C'est simple, sans ZeMarmot, pas de GIMP. Je contribuerai alors sûrement à d'autres logiciels libres, selon mes autres besoins, mais je n'ai pas besoin de GIMP personnellement plus que ça (enfin régulièrement, je découpe, redresse, rend plus net, etc. des photos; mais pour cette utilisation basique, GIMP est déjà largement au niveau). Là on en a vraiment besoin, dans un projet professionnel, au quotidien 8h par jour.
(0) On a besoin qu'il soit stable. Quand on faisait les premiers tests avec Aryeom Han, GIMP crashait pour un rien (c'était vers 2012). Ça foutait la honte. Mes premières années de contribution, j'ai corrigé beaucoup de crashs (de mémoire, y en avait en utilisant une tablette graphique; y en avait aussi des supers mauvais lorsqu'on utilisait un IME, en particulier avec le coréen, dans l'outil texte, et plein d'autres dont je me souviens même plus) et autres problèmes de stabilité. Bon j'en corrige encore régulièrement, mais GIMP est devenu beaucoup plus stable.
(1) Toujours dans la recherche de stabilité, on a besoin de pouvoir aisément débugger et parer aux problèmes (qui arrivent sur tous logiciels même les plus stables). Donc j'ai implémenté une sauvegarde des images au moment du crash (pour ces bugs survivants qu'on n'a pas encore corrigés!), et GIMP propose maintenant au lancement suivant de tenter une récupération des images qui étaient en cours d'édition, ainsi qu'un système de débug qui génère automatiquement des backtraces, non seulement pour les crashs, mais aussi utilisables lors de WARNING et CRITICAL en cours d'utilisation (permet d'améliorer le logiciel en découvrant des bugs plus subtils). C'est l'une de mes fonctionnalités fétiches. Le nombre de bug qu'on a pu corriger depuis que j'ai implémenté cette fonctionnalité est impressionnant. Corriger des bugs est devenu simple, et les gens nous envoient désormais des rapports de bugs utiles, même lorsqu'ils ont aucune idée de ce qu'il s'est passé, qu'ils savent pas du tout parler anglais ni écrire des rapports de bug bien formés.
(2) On rajoute des fonctionnalités. Dernièrement je travaille beaucoup sur tous les détails pour les écrans haute densité de pixel (l'écran principal de travail d'Aryeom ne l'est pas pourtant, mais je sais qu'on y viendra; autant préparer GIMP en amont). Le système d'extension indiqué plus haut bien sûr me semble important. Nous aussi on utilise quelques plug-ins, mais très peu. Franchement c'est impossible de savoir ce qui existe et ce en quoi on peut faire confiance. Et surtout chercher, installer et faire marcher des vieux plug-ins peut être une vraie galère (et pourtant je suis développeur, c'est dire!).
Dans les quelques années passées, j'ai été responsable de plusieurs autres fonctionnalités, et je travaille à d'autres fonctionnalités encore (comme l'animation, comme on sait ici).
(3) On fait de la revue de code. Ça paraît bien moins sexy, mais c'est primordial. L'histoire de GIMP est parsemée de fonctionnalités sympas qui ont été perdues car personne n'a eu le temps de les vérifier. Je ne jette la pierre à personne: ça prend un temps fou. Dans cette sortie par exemple, l'écriture verticale n'aurait probablement jamais été intégré sans moi (je suis allé chercher le contributeur, j'ai fait la revue, les tests, les commentaires sur chacune de ses modifications; en tout j'y ai passé quelques heures).
Même le Marathi, j'ai vu un email perdu sur la liste de discussion des traducteurs auquel personne ne répondait; le problème est que cette langue n'avait plus de coordinateurs. J'ai donc essayé de relancer à la place des traducteurs (qui allait sûrement abandonner à un moment donné) et de leur donner espoir pour ne pas les décevoir (un espoir qui a abouti!).
Le redressement horizontal, j'ai retrouvé un vieux patch perdu dans le bugtracker et très basique. J'ai fait de la revue, retravaillé au dessus (car il n'était pas vraiment utilisable en l'état); Ell a fait de même ensuite. Et maintenant ça fait une super fonctionnalité.
Dans le passé, je me souviens bien de la recherche d'action (une de mes fonctionnalités préférées!). J'y ai passé un temps considérable. Le patch était cool, mais écrit par des étudiants. J'y ai passé de très nombreuses heures à corriger ce qui devait l'être, à rendre la fonctionnalité vraiment utilisable simplement, et à l'améliorer énormément. Maintenant je pourrais pas faire sans!
Pour info, dans GIMP, on a des règles stricts et du code de très bonne qualité globalement (bien sûr plus localement, on trouve beaucoup d'horreurs ici et là, comme dans tout gros code). Donc la revue est primordiale. On fait pas comme certains logiciels qui acceptent tout et n'importe quoi.
(4) On fait évoluer la politique interne. Je suis celui notamment qui a poussé depuis plusieurs années (tous les ans, à chaque fois qu'on se rencontrait au Libre Graphics Meeting) pour une nouvelle politique de sortie permettant de sortir des versions macros avec de nouvelles fonctionnalités (plutôt qu'attendre 6 ans encore pour une sortie majeure!). Et voilà, maintenant tous les mois, GIMP sort avec des fonctionnalités cool. Les gens se disent maintenant que GIMP est super actif, et on se met à avoir plus de contributions (j'ai l'impression; mais ça peut aussi être simplement car on a sorti 2.10, ou autres raisons).
(5) On a créé et on maintient le flatpak pour que les linuxiens aient GIMP facilement et rapidement à chaque sortie (GIMP est maintenant dispo sous Linux à chaque sortie avant toutes les autres plateformes!).
Et sûrement plein d'autres choses.
Ensuite soyons clair: je ne souhaite pas mettre tous les éclairages sur ZeMarmot uniquement. En particulier le mainteneur, Mitch, fait un travail de dingue, connaît le code de GIMP et ses rouages bien mieux que moi. Sans parler de Ell, un alien venu d'ailleurs, qui nous optimise GIMP aux petits oignons (avec du code d'excellente qualité) depuis qu'il est arrivé. Je ne suis pas seul (heureusement!), et on a tous les 3 une grosse part dans le succès de GIMP.
Mais clairement je ne pense pas que ce soit exagéré d'affirmer que le projet ZeMarmot a vraiment contribué largement à propulser GIMP dans une nouvelle ère. On travaille sur GIMP pour un vrai projet, au quotidien (oui je me répète) et ça vaut énormément de contributions aléatoires sans but. C'est un peu une symbiose de l'artiste et des outils. Chacun a besoin de l'autre.
Si avec cela, ce n'est pas suffisant, alors je ne sais pas ce qui l'est. Je rappelle qu'on est officiellement associé à GIMP d'ailleurs (bien sûr même! Je suis un dév majeur). Même le site web gimp.org suggère de donner directement à ZeMarmot sur la page donation, ainsi que dans ses news régulières (comme la dernière news dont cette dépêche sur Linuxfr est plus ou moins une traduction un peu retravaillée). J'aurais du mal à voir comment ça pourrait être plus limpide. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
On sait pas trop non plus. J'ai aussi vu passer des trucs vite fait, mais rien qui dit clairement "c'est bon, tout va bien". Ils font pas beaucoup de communications, c'est dommage.
J'aime beaucoup Liberapay, mais tant qu'on n'a pas de message clair comme quoi ils sont à nouveau dans la course, on peut pas vraiment donner le lien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tu me reprends sur la distinction entre manager et gérer ? :)
Tu parles du fait que c'est de la gestion d'extension dans GIMP? Si oui, bien sûr que là on parle de gestion (c'est même le titre), mais il s'agit du fait d'installer, désinstaller, mettre à jour et afficher des infos sur des extensions. C'est la partie côté cliente.
Ça veut pas dire qu'on gère l'extension au sens de vraiment s'en occuper. Si elle est bourrée de bugs, si elle marche pas même, c'est pas notre problème au delà de fournir des outils (pas immédiatement, mais probablement rapidement) pour que les gens puissent indiquer une extension qui fonctionne ou pas sur telle ou telle version de GIMP. Et si l'extension n'est pas maintenue, on ne s'en occupera pas plus.
Je dirais que c'est notre problème si on découvre des malware et là oui, on intervient et on vire l'extension. À ce moment, quand il y a intention malfaisante évidente (ou grosse faille de sécurité très dangereuse), il est évidemment de notre responsabilité de réagir. Mais ça s'arrête là. C'est en ce sens là qu'on ne gère pas les extensions (côté serveur) au delà de proposer aux gens de les héberger.
Ça se discute. Tu pensais faire des revues pour les brosses par exemple ? Ce sont des vecteurs d'attaque eux aussi. On peut voir le chargement d'un fichier comme une exécution d'un programme dans une sandbox et c'est régulièrement un vecteur d'attaque.
Les données inertes (brosses, images splash, thèmes, icônes, dégradés, etc.) ne subiront en effet pas de revue préalable, contrairement aux données exécutées (plug-ins) qui doivent être évidemment validées avant d'être diffusées.
Ensuite bien sûr que des vecteurs d'attaques peuvent exister avec des données inertes. Cela a toujours existé et existera toujours. On a tous entendu parler de failles permettant d'exécuter du code caché dans des images par exemple.
Néanmoins cela n'est pas un comportement normal, et ainsi dire "On peut voir le chargement d'un fichier comme une exécution d'un programme dans une sandbox" est faux, en tous cas pour le type de fichiers que tu cites (brosses) ou que je cite (images) [bien sûr, il existe des fichiers avec du code fait pour être exécutés, comme les fameuses macros de traitement de texte; de tels fichiers doivent donc être considérés comme du code]. Donc non, charger une bosse ou une image n'est pas la même chose qu'exécuter un programme. Ce sont des données inertes faites pour une utilisation donnée, pas pour exécuter du code tiers. Quand cela arrive, c'est un comportement anormal, autrement dit un bug (le plus souvent dans le logiciel, parfois dans le format lui-même) et qui doit alors être corrigé.
Aussi cela n'a rien à voir avec les extensions. Ce type de bug, quand il existe, existerait déjà dans GIMP et pourrait déjà se produire. Les extensions ne sont qu'un conteneur supplémentaire (ajoutant un peu de sémantique au contenu, indiquant de quoi il s'agit, un nom, une description, des liens annexes, une version, etc.).
Alors c'est pas si simple, je sais que ce n'est même pas le début du projet, mais ça rend publique toute une politique et ça vous expose à du bad buzz (grand publique ou de communauté), des discussions interminables, etc.
Les haters ont toujours existé et existeront toujours. Je le sais bien, je parle moi-même régulièrement sur Linuxfr de cela. Soyons clair, ça me touche et c'est dur. Mais je ne vois pas en quoi faire ou non des extensions pourrait changer quoi que ce soit à cela.
En fait par rapport aux comportements inadéquats, ma politique perso est de rester neutre (si possible, parfois c'est dur de tenir) et d'expliquer aux gens justement ce que je disais: GIMP est un logiciel libre, le logiciel libre, ça ne marche pas comme ils semblent le penser. En plus on n'est pas une entreprise, et on développe de façon volontaire. Et non, on ne réagit pas bien aux menaces et insultes. Par contre on est heureux d'aider les gens agréables, et tout ce qu'on demande, c'est que ces gens comprennent aussi ce qu'il en est, et qu'on contribue principalement bénévolement, souvent sur du temps libre.
Eh ben, tu me croiras peut-être pas, mais être clair (et poli) désamorce pas mal de situations. Les gens se rendent compte qu'ils ont un peu été des malotrus, se calment, parfois même (ça arrive!) s'excusent.
Ensuite oui, ça n'est pas du 100%. Et certains sont juste là pour haïr, comme je disais. On ne peut rien pour cela. Mais encore une fois, je vois pas le rapport avec les extensions. Ces personnes trouveront de quoi redire pour chaque nouvelle fonctionnalité qu'on apportera. On va quand même pas s'arrêter d'améliorer nos logiciels pour ces gens là! En tous cas, perso, c'est pas pour eux que je développe. :-)
est-ce que les développeurs auront suffisamment la foie pour ne jeter l'éponge ?
Je crois que tu cherches des problèmes là où y en a pas. :-)
Pourquoi qui que ce soit jetterait l'éponge pour quelques aigris? Si ça devait arriver, crois moi, ça serait arrivé y a trèèèès longtemps (comme tout gros logiciel connu, on collectionne quelques aigris).
Au pire du pire, si vraiment ça se passait super mal, on pourra toujours arrêter notre système d'extensions tiers (et n'héberger que nos propres extensions, voire un choix très restreint d'extensions sélectionnées au cas par cas, comme quelqu'un le propose plus haut). Perso je trouverais cela un peu dommage, mais si on devait en arriver là, c'est pas la mort.
Soyons clair, je ne pense pas qu'on en arrivera là. Je vois aucune raison à cela.
Ah oui, et:
bad buzz
Encore une fois, du vocabulaire de startup hipster. On s'en fout du "bad buzz". Je dirais même qu'on vit dans un monde où cela n'existe pas. Il y a des gens sympas, des gens moins sympas, ça s'arrête là. Si ce prétendu grand méchant bad buzz devait avoir eu raison de nous, ça serait arrivé y a très longtemps.
Je préfère t'avertir de mes craintes, pour que tu sois moins surpris si (malheureusement) ça arrive.
Merci beaucoup de t'inquiéter pour nous.
Je pense perso que tu te fais du mouron pour rien. :P
Si le type de problème dont tu parles devait arriver, je pense pas que ce soit parce qu'on ait ajouté un système de gestion d'extension dans GIMP. Ahahahah!
Sur ce, j'arrête de répondre sur cette news. J'ai un peu l'impression de trop l'accaparer en hors-sujet là, alors que c'est censé parler de ce super logiciel qu'est G'Mic. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Nos installeurs contiennent la version 32 et 64-bit et installent la version appropriée. C'est écrit juste sous le bouton de téléchargement. Donc prends simplement l'installeur unique et ça te mettra la bonne version.
ou en fait uniquement pour Windows >=7
Ça oui par contre. C'est pas qu'on veut pas prendre en charge de plus vieux Windows, mais on n'a quasi aucun dév Windows (approximativement 0) alors on fait ce qu'on peut. Prendre en charge de vieilles versions veut dire plus de boulot car on doit contourner des problèmes de manières plus compliquées (même si des versions récentes ont peut-être amené des solutions simples).
Notre ligne directrice pour savoir si on prend en charge un OS (Windows ou macOS), c'est que cette version de l'OS doit au moins être encore pris en charge par son éditeur. Windows XP, y a plus de support depuis avril 2014 (d'après Wikipédia) et on parle quand même d'un système sorti en 2001, soit y a 17 ans!
Il est peut-être temps de mettre à jour. Et si le matériel est juste trop ancien, on peut mettre un Linux avec bureau léger. Ou si vraiment on est nostalgique des vieilles années et qu'on veut garder l'OS d'époque absolument (faire attention à l'accès internet, etc. dans ce cas), ben on prend sur soi et on garde aussi les vieux logiciels (y compris GIMP 2.8). :-)
Enfin bon, tout cela pour dire qu'il n'y a pas vraiment de solutions miracle, désolé. On peut pas prendre en charge indéfiniment un système, surtout si même son éditeur ne veut plus le prendre en charge. Ce serait vraiment se tirer une balle dans le pied.
Je veux bien le compiler, mais c'est possible de le compiler en 32 bits pour XP (et un CPU Pentium3) avec Visual Studio (MSVC), ou faut obligatoirement utiliser un autre système de build ?
Tout est possible. Ensuite je crois que la plupart des gens qui compilent GIMP pour Windows le font depuis un Linux (même notre build officiel est cross-compilé, il me semble). Donc ce sera clairement cela le plus simple.
Et je suis pas certain que ce build fonctionnera de toutes façons. Ne pas prendre en charge Windows XP, ça veut surtout dire qu'on a peut-être (probablement) utilisé des APIs Windows qui n'existaient pas encore dans XP. Donc tu te retrouveras à devoir patcher le code en fonction des parties qui poseront problème. Si tu le fais sans perte de fonctionnalité ni rendre le code surcompliqué (et avec un code propre), on veut bien le patch (on n'est pas absolument contre Windows XP, on ne le prend pas officiellement en charge, c'est tout).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Quand tu gère des extensions du deviens responsable au moins en parti d'elles.
On ne les gèrera pas. On les hébergera. Mais oui tu as raison quand même qu'on aura notre part de responsabilité.
Actuellement rien ne cloisonne les extensions, donc tu veux faire de la revue et le build chez toi.
Même si GIMP lançait des sandbox, la revue et compilation doivent être faites de notre côté. Héberger aveuglément un binaire d'inconnus complets est une aberration.
C'est la raison pour laquelle les plug-ins compilés ne seront pas acceptés tant qu'on n'aura pas l'infra. Certains bénéficieront d'exception évidente comme G'Mic. C'est expliqué dans mon article.
C'est super comme idée, mais je crains que ça ne consomme toute ton énergie (je serais heureux de me tromper !)
Je ne prévois pas de gérer le site. Je suis développeur pas animateur de communautés. Nous avons une très grosse communauté avec des gens très actifs et même pas mal plutôt techniques. Des gens comme Pat David et Elle Stone seront parfaitement capables de gérer le quotidien (et de sélectionner les futur modérateurs si le contenu grossit vite).
Aussi on pourra y aller lentement. Si les gens sont pas contents du temps de revue, ce n'est pas notre problème. L'un des énormes avantages que l'on a est qu'on n'essaie pas de faire du business. Nos actions ne sont pas dirigées par des contraintes économiques. Ça rend GIMP très résistant aux problèmes car personne ne peut nous forcer à rien ni nous presser.
Bon j'arrête là. Cette dépêche est au sujet de G'Mic pas de GIMP! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Non ce n'est pas envisageable. De même que notre installeur Windows ne contient pas G'Mic (pas plus que tout autre plug-in tiers), ni notre DMG pour macOS.
Les builds officiels de GIMP ne contiennent (et ne contiendront toujours) que les plug-ins core de GIMP, c'est à dire ceux maintenus par les développeurs de GIMP. On a déjà bien suffisamment de boulot (avec très peu de développeurs) pour ne pas non plus se donner plus de travail. En outre si quelqu'un fournit un paquet, il est de-facto responsable de son contenu (or on ne développe/maintient pas G'Mic). Pour G'Mic, c'est un logiciel suffisamment complexe et élaborée pour qu'on se rende bien compte que si David venait à arrêter demain (on touche du bois pour que ça ne soit pas le cas!), on ne serait pas à même de le maintenir à sa juste valeur.
Donc non, on ne peut pas.
De même que David, je pense qu'il préfère garder l'indépendance dans ses sorties, etc. et ne pas dépendre de nos choix de sortie.
La tendance est plus à la création d'un système d'extension (voir ma news pour GIMP 2.10.6 qui devrait être publiée d'ici quelques jours) qui permettra d'installer facilement G'Mic et autres plug-ins, tout en laissant les développeurs de ces plug-ins en garder la main complète. Tout le monde y gagne. Et je sais, de source sûre, que David aime l'idée. ;-)
D'ailleurs une fois que cela sera en place, il est même possible que certains des plug-ins core actuels puissent devenir des extensions à leur tour (toujours maintenus par nous, mais avec un rythme de développement parallèle), ce qui permettrait des menus moins touffus de fonctions que peu de monde utilisent par exemple. À voir…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Perso je pense que la prévisu sur canevas serait super utile, même pour les traitements lents.
Pour ma part, je trouve donc que l'idée d'adopter systématiquement une prévisualisation on-canvas n'est pas excellente.
La prévisualisation n'a pas à être activée par défaut. ;-)
Il vaut mieux dans ce cas pouvoir effectuer les traitements plutôt sur de petites portions d'images pour prévisualiser le résultat.
GIMP donne aussi la priorité au rendu de la partie visible à l'écran, et le mipmapping aide aussi beaucoup si un zoom (avant ou arrière) est fait. Et je sens que les choses vont s'améliorer encore dans le futur pour optimiser la sensation de fluidité (ou du moins de pas avoir une expérience trop désagréable), même avec des traitements lents.
L'édition non-destructive aura a priori le même genre de limitations.
Ce sera clairement utile pour l'édition non-destructive également. Faire un changement dans les paramètres d'un effet peut te prendre 10 minutes, mais dans tous les cas, tu devras le refaire (ton effet). Dans le cas de l'édition non destructive, au moins tu pourras voir les paramètres utilisés précédemment et repartir de là. Dans le cas de l'édition destructive, tu as intérêt à avoir bien gardé une copie du calque d'origine et tu ne sais même pas l'ensemble des traitements faits, et avec quels paramètres, à part si tu les as notés bien consciencieusement (ce que certains font dans le nom du calque par exemple).
Pour moi, il n'y a rien d'équivoque là. Mais je crois qu'on a déjà eu cette discussion et qu'on pourra encore l'avoir à l'avenir. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
j'ai aussi souvenir d'un dev' de chez GNOME ou GIMP, je ne sais plus, assez imbus de lui-même, qui ne donnait pas spécialement envie d'utiliser GIMP
Je ne contribue que depuis (relativement) récemment, c'est à dire depuis 2012. Mais il paraît que certains des anciens contributeurs de l'époque d'avant n'étaient pas très cool, voire peut-être même un peu toxique. Mais ce n'est que du "on dit" car je ne les ai pas connus.
En tous cas, de nos jours, ce n'est plus le cas. :-)
[HS]Vous ne faites plus de lives ZeMarmot ? J'y passais de temps en temps même s'il n'y avait pas grand monde, c'était reposant de regarder quelqu'un dessiner. Après j'imagine que monter tout le setup pour si peu de résultat était peut-être un peu frustrant.[/HS]
On a un peu mis en pause pour diverses raisons. Déjà y a le côté technique. Le logiciel de streaming (libre) faisait quand même beaucoup souffler la machine (qui a déjà beaucoup à faire quand on fait de l'animation), voire était plutôt instable (cela nécessite OpenGL 3.2, ce qui veut dire qu'on doit installer les pilotes Nvidia proprio, et même là, ce n'est pas parfait). Le pire n'est pas seulement que ça plantait parfois, mais qu'il arrivait à faire freezer la session graphique de temps en temps. OBS Studio est cependant très connu et une référence a priori chez les gens qui font du live, même s'ils savent pas que c'est libre. Y a peut-être quelque chose à configurer mieux. Et aussi j'ai cru comprendre que la version Linux est moins stable de manière générale. À voir…
Ensuite oui, y avait pas tant de monde, et on se disait que ça valait pas forcément le coup.
Mais surtout, Aryeom a eu une petite période de blues ces derniers mois (je l'ai déjà dit, l'un comme l'autre, on se pose beaucoup de questions; on nous dit constamment que GIMP peut lever beaucoup de financement participatif, mais dans les faits, notre financement est faible), voire un petit burnout. Donc elle a préféré continuer à travailler sans les lives. Mais là je lui ai montré ton message, et elle se dit qu'il faut peut-être les recommencer. On verra!
P.S.: ne pas hésiter à laisser un message si on reprend les lives. Ça fait toujours plaisir et ça donne moins l'impression de faire un direct dans le vide. Faut pas donner tous les mercis qu'à moi. Y aurait rien de tout cela sans Aryeom non plus.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
"22 commits par jour"
[…]
Tu parles de "depuis 2.10.2" et je ne sais pas quand tu as fait le calcul
Je ne me souviens plus du calcul exact de l'époque mais je peux en refaire un.
En gros, je regarderais les commits faits entre GIMP 2.10.2 et 2.10.4, et ce, sur master, car c'est là où se passe vraiment le développement (pas sur la branche gimp-2-10 en particulier qui ne contient que les backports pour la série stable).
Sur master, y a un tag GIMP_2_10_2 mais pas GIMP_2_10_4 car on a créé la branche gimp-2-10 justement à la sortie de GIMP 2.10.2 (donc c'est là où les 2 branches ont commencé à diverger). Pour le commit d'arrêt, je vais donc prendre un commit qui correspond à la date de sortie de GIMP 2.10.4, soit le 2018-07-04. Je prends le dernier commit à cette date. Note que ce n'est probablement pas le calcul que j'avais fait à l'époque, car j'imagine que j'avais pris HEAD qui était sûrement différent à l'époque (soit un peu avant, soit un peu après la sortie. Je ne suis pas sûr quand j'ai démarré cette dépêche collaborative). Quoiqu'il en soit, voyons le nombre de commits:
Comme il s'agit d'une période de 45 jours, je fais une moyenne, soit: 972 / 45 ≈ 21,6. Voilà (avec un arrondi, ça fait 22 ;p).
Ensuite soyons clair: GIMP 2.10.2 est le moment où on a divergé vers le port GTK+3, comme je viens de le dire, donc ça veut notamment dire qu'on a mergé tout le travail fait sur GTK+3 (dont la majorité avait été faite ce même avril/mai, après la sortie de GIMP 2.10.0!) d'un seul coup. En un sens, ça a clairement boosté les statistiques. D'un autre côté, tant qu'on ne merge pas une branche de fonctionnalité, elle ne rentre dans aucune statistique. Faut bien qu'elle le rentre un jour (de même que j'ai des dizaines de commits qui attendent dans des branches de fonctionnalité en cours, et un jour, je les verserai dans master d'un coup, mais en attendant, c'est comme si ils n'existaient pas). De toutes façons, il y avait clairement un moment, qui correspond à la sortie de GIMP 2.10.0 où on a vraiment eu un gros pic de contributions.
Si maintenant tu remontes plus loin, par exemple le début d'année, comme tu le proposes, on a une moyenne à 11 commits par jours:
"plusieurs années que le développement est aussi actif"
De manière générale, il y a forcément des hauts et des bas dans le développement. Surtout que comme on est 3 à faire la plupart des commits, forcément il suffit qu'il y ait une période où l'un de nous est peu actif pour que les stats baissent (par exemple pour le mainteneur, c'est souvent les fins d'année où il a moins le temps de contribuer car il a un commerce), de même qu'y a des périodes où tout le monde s'active. Quand je dis qu'on est très actif depuis des années, ça veut pas dire qu'y un taux constant de contributions à tout moment (ce serait pas humain!). D'ailleurs, ailleurs dans un commentaire, je dis même que notre développement s'accélère au contraire (ce qui ne veut pas dire que ça ne va pas se calmer à un moment, et puis de toutes façons, il y a des limites humaines à notre rythme de contributions!). Voilà, donc en gros, faut pas non plus s'attacher au mot près. Je donnais les stats entre 2.10.2 et 2.10.4, qui étaient effectivement de 22 commits par jour en comptant dans git, et c'était effectivement un très gros pic.
Enfin les stats, c'est aussi beaucoup du "marketing", soyons clair. De toutes façons, on peut faire dire beaucoup de choses aux nombres, on le sait tous. Rien que le choix d'unités est sujet à critique. Un commit, est-ce vraiment un critère adéquat? Faut-il compter le nombre de lignes à la place? Compte-t-on alors les lignes de commentaires (important aussi) ou juste le code pur et dur? Et qu'en est-il de ceux qui ont un code plus concis ou plus élagué (par exemple déclaration et définition sur des lignes distinctes, etc.)? Comment compte-t-on le temps de recherche, diagnostic, lecture de docs? Le temps pris pour des choses (importantes) autre que du code (écriture de news, docs, etc.), même? D'ailleurs peut-on même simplement compter le temps passé par les contributeurs pour GIMP (réponse directe: non, c'est du logiciel libre, on sait pas combien de temps passe chacun), et alors qu'en est-il des gens simplement plus efficaces que d'autres? Etc. Etc. Etc.
Ma conclusion, c'est que ce sont des stats. Les miennes étaient vraies (comme montrées plus haut) car notre branche master a réellement 22 commits par jour entre GIMP_2_10_2 et la sortie de 2.10.4. Ensuite ça vaut ce que ça vaut (pas grand chose, ou beaucoup, c'est selon).
Là où je voulais en venir avec ces stats, c'est que c'est du développement vraiment très actif. Et d'ailleurs tu es d'accord sur ce point. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ah je pensais que tu parlais du développement en cours, parce qu'on nous fait souvent la remarque qu'on devrait sauter direct à GTK+4. On y a pensé nous-même d'ailleurs (on a une news vieille d'avant même la sortie de 2.10 où on évoque la possibilité) mais on a décidé que ce n'est pas une bonne idée (pas avant stabilisation du moins).
Je sais bien qu'on approche enfin du bout du tunnel et que la prochaine version majeure sera la bonne, mais je doute que ce soit encore pour cette année. Je me trompe ? :D
Ahahah. Qui sait?! Moi j'en sais rien en tous cas. On y travaille, mais on donne pas de dates. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je pense que tu te méprend sur mon commentaire (ou alors, je me suis vraiment mal exprimé, et je m'en excuse).
T'inquiètes, je n'avais pas pris mal ton commentaire. J'essayais simplement d'y répondre pertinemment. Le fait est que quand on fait quelque chose similaire à notre projet, on semble se récolter tous les conseils du monde. Ce n'est pas mal, soyons clair. C'est un peu fatigant, mais ce n'est pas mal. D'ailleurs je suis sûrement aussi le premier à donner des conseils à d'autres quand ils se lancent par exemple en indépendant (je ne suis d'ailleurs pas certains si mes conseils sont si pertinents et si je contribue pas à fatiguer ces gens, même s'ils ne me le disent pas par politesse).
Le truc, c'est aussi que beaucoup de ces conseils sont des trucs que je sais, ou même que je sais ne pas marcher, voire souvent que j'ai déjà essayé maintes fois. Je pourrais te citer toute une liste des classiques (mais je vais pas le faire sinon rallonger encore plus le commentaire).
Dans ce fil, on me propose de faire une fondation GIMP (je l'ai entendu 20 fois), qu'il faut plus d'argent (captain Obvious), que beaucoup attendent les fonctionnalités X ou Y (on accepte les patchs!). D'ailleurs la pertinence de ta liste de fonctionnalités est vraiment sujette à question. Genre quand tu me dis:
Et même si le développement est vraiment actif, la première chose que l'on voit, c'est que Gtk+ 4 va bientôt sortir, mais que GIMP utilise toujours une version obsolète
Ben… non GTK+3 n'est pas obsolète. C'est la version à jour de GTK+. Non, on ne va pas commencer à travailler sur une version "mouvante", pas sortie et donc qui va constamment casser son API. On a bien assez de boulot (et comme tu le notes, on est peu nombreux). Travailler sur une version de développement serait comme se tirer une balle dans le pieds pour être sûr que GIMP 3 ne sorte jamais (ou dans 10 ans) et qu'on ait constamment à corriger notre code (comme si on n'avait pas assez de travail!). Surtout qu'on parle de GIMP, pas d'une petite application mono-fonctionnalité de 10 000 lignes de code (qui elle, oui, peut se permettre des changements dans son toolkit, éventuellement… enfin si elle ne prévoit pas de sortir d'ici quelques années!).
Nous avons une règle au sujet de nos dépendances pour la branche master: il faut qu'elle soit dispo dans Debian Testing. Cela la rend suffisamment récente pour travailler avec des dépendances qui ne sont pas dépassées, et en même temps, on sait que cette dépendance fera son apparition dans les autres distribs d'ici 1 an ou 2.
Attendons que GTK+4 sorte et soit stable pour le considérer.
Tu vois, clairement, c'est aussi un conseil de quelqu'un qui n'est pas sur le terrain. :P
Mais reconnais que vous êtes une petite équipe. Si demain il devait arriver malheur à l'un d'entre vous (ne serait-ce que Mitch ou toi), ou que pour x raison vous ayez soudainement envie de passer à autre chose, le développement serait sérieusement ralenti.
C'est vrai, mais c'est le cas de 99.99% des logiciels Libres. Je viens de regarder (encore) l'activité de Blender. Ils ont à peine plus de gros développeurs que nous (si je regarde 2018, je dirais 4 vraiment gros développeurs). Ensuite oui, je suis sûr que Firefox ou Apache n'ont pas ce problème. Mais pour en arriver là, ce n'est pas juste un ou 2 commerciaux qu'il faut engager.
Donc non, la professionnalisation ce n'est pas un gros mot.
Et je suis totalement d'accord, puisque j'ai répondu que c'est exactement ce que l'on fait! ;-)
Comme l'a mieux expliqué Zatalyz, ça commence par trouver quelqu'un capable de faire du marketing et trouver des financements
Il y a un million de trucs à répondre à ça! Déjà, comment le paie-t-on? On est une asso, on fait du tout-libre, etc. Donc effectivement si quelqu'un veut aider bénévolement parce qu'il veut promouvoir le la création Libre (un des objectifs de l'asso), on n'est pas contre. Dans les faits, on a eu des aides ponctuelles déjà, de par le passé, mais on ne va pas pousser ces gens à travailler d'arrache-pied sans être payés. Perso j'aimerais que tous ceux qui travaillent soient payés (correctement en plus), idéalement. Je fais partie de ces gens qui considèrent que c'est normal de payer quelqu'un pour un travail et je ne veux surtout pas trop profiter des gens (même raison pour laquelle je n'aime pas les stages par exemples, et surtout les stages non-payés; on nous en a encore proposé y a pas longtemps et c'est pour moi de l'exploitation de jeune mains d'œuvre). Or si on paye cette personne, ben nous on n'a plus de sous (je rappelle que depuis quelques années, on jongle avec quasi rien).
Ensuite y a la fameuse réponse, oui mais cette personne est censée ramener plus que ce qu'elle coûte! Donc une fois engagée, elle ramènera de quoi vous payer. Déjà ce n'est pas sûr. De même que j'expliquais qu'il peut y avoir de mauvais dévs, il peut aussi y avoir de mauvais commerciaux (quand on parle de financement, ou marketing pour la pub; au passage, tu me parles de 2 postes différents là comme si c'était la même chose!). Donc ce n'est pas sûr qu'ils ramènent quoi que ce soit. Peut-être se retrouvera-t-on à les payer pendant 6 mois sans qu'il n'y ait aucun retour puis on doit leur dire au revoir, et entretemps, le projet a pu tomber à l'eau (car un développeur et une réalisatrice, ça mange aussi). Ensuite y a le fameux sujet: ces gens sont-ils vraiment ceux qui ramènent l'argent? On retrouve souvent ce sujet de discussion lorsqu'on se demande s'il est vraiment normal de payer des CEOs des prix exorbitants (et l'une des 2 réponses est souvent: oui mais ils sont censés ramener plus que leur salaire). Soyons honnête 2 minutes, les commerciaux sont ceux qui mettent leur nom sur le papier et qui signent, mais en général, sans le travail des techniciens (développeurs, animateurs, etc.) qu'ils ont vendus, y aurait rien eu à vendre. Prenons l'exemple de cette récente donation de 400 000 $ à GNOME/GIMP. Cela a-t-il été ramené par les commerciaux/CEO en arrière-plan qui ont démarché le donateur? Peut-être (ou pas, j'en sais rien, c'est pas écrit). Ce donateur aurait-il donné de toutes façons si y avait juste eu des développeurs parce qu'il aime GNOME/GIMP indépendamment d'un quelconque démarchage? Peut-être aussi. Le fait est qu'on n'en sait rien pour GNOME. Ce n'est malheureusement pas si simple à répondre, mais il est vraiment très pertinent de se poser la question.
Par contre côté GIMP, on peut répondre tout de suite: on ne savait rien de cette affaire, on n'a pas démarché, donc cette donation n'a rien à faire avec un quelconque marketing/commercial (et non ce n'est pas GNOME qui a demandé pour nous). Ce qui tend à invalider l'assertion qu'il faille du marketing pour de gros financements. :-P
je vois que chez Wikimedia […]
Très bon exemple, si je me souviens bien, à l'époque (qui a duré de nombreuses années, alors même que Wikipédia était déjà connue et dans le Top 10 mondial des sites visités), leur seul employé était un admin. Car au final, ça sert à rien d'avoir du marketing et du commercial si l'exécutif ne fonctionne pas. La première chose à faire, c'était d'avoir un site qui fonctionne. De même que pour nous, la première chose, c'est de faire un film. :-)
Ça ne serait pas mieux de ne plus avoir à se soucier de tous ces problèmes, de pouvoir bosser sereinement sur un projet qui te tient à coeur ?
Alors oui, je suis entièrement d'accord avec tout ce que tu dis sur le fond. Je ne me méprenais pas sur ton commentaire précédent non plus, de même que je veux être clair pour que tu ne te méprennes pas sur le mien. Mes réponses ne sont pas aigries ni en colère, ni quoi que ce soit de négatif. C'est pour cela que j'essaie de les parsemer de smileys (mais apparemment ça marche pas). Et là, quand je te réponds, je souris. Promis, c'est pas un mensonge! :P
Je sais aussi que mes longs commentaires à rallonge (j'arrive pas à faire court!) peuvent faire croire le contraire, mais ils ne signifient pas un état de désaccord.
Donc, reprenons: oui je suis d'accord… mais comme je l'ai expliqué, ce n'est pas si simple. Dire "il vous faut du marketing", c'est une recette de grand mère qui est à la fois évidente et à la fois pas en phase avec le monde réel qui ne prend pas en compte le fait qu'il faut payer cette personne, que ce n'est pas dit que cette personne va vraiment ramener des fonds, et surtout que ce n'est absolument pas sûr que je n'aurais plus à me soucier de rien. Par exemple, je l'ai dit, par le passé, on m'a déjà proposé de m'aider pour du financement (qu'on n'a pas eu), et au final, j'ai passé 90% du temps sur le dossier car c'est moi qui connaissais le mieux le dossier (note que je n'en veux pas du tout à cette personne qui m'a quand même aidé sur les 10% et je suis reconnaissant, mais c'est pas ce que j'appelle "ne plus se soucier des problèmes"). Ça c'est la réalité. :-)
Alors oui, LILA existe déjà (à qui je donne dix euros tous les mois)
Merci beaucoup pour cela! :-)
Perso je relativise notre taille. Oui on est petit et ridicule, et c'est pour cela qu'on ne peut pas engager quelqu'un en espérant qu'il soit doué et ramène soudainement beaucoup, tout en se mettant à négliger tout l'exécutif. En même temps, on arrive à tenir depuis quelques années. J'y crois personnellement. Certes cela ne m'empêche pas de régulièrement rappeler les gens de notre existence en demandant de nous soutenir, mais je suis confiant que ça va aller en s'améliorant, même si j'ai aussi mes périodes (très régulières) de doute.
En fait je pense que tes conseils sont vrais, mais simplement mettent la charrue avant les bœufs. Ils ne seront applicables que quand l'asso aura réussi à nous rémunérer convenablement d'abord. Un projet qui ne pense pas à l'exécutif d'abord ne vaut rien. Et ce jour là, quand on aura des sous en plus, alors on pourra penser à engager du marketing.
Wikipédia, c'était pareil, ils ont commencé par rémunérer l'exécutif. De même que la fondation Blender, quand ils ont eu des sous, ils ont payé du développement (et des animateurs avec leurs fameux Open Projects), etc. On ne commence pas un projet sans sous avec du marketing et du commercial. Enfin si, certains le font. On appelle ces projets des vaporwares. :P
En tous les cas, c'est mon point de vue et aussi la position de LILA à ce jour. Peut-être qu'on a tort (mais je crois pas).
Ah et dernier détail: tu ne peux pas nous comparer avec la Blender Foundation (née en 2002), la Wikimedia Foundation (2003), la Mozilla Foundation (2003), la Linux Foundation (2000) ou je-ne-sais quelle autre fondation ou association qui ont 15 ans ou plus, qui fonctionne confortablement et avec laquelle tu nous compares (nécessairement car tu cherches des points de comparaison et ce sont les organismes que l'on connaît bien dans le Libre). LILA existe techniquement depuis presque autant (on l'a fondé avec un ami en 2005, pour un projet de Musique Libre qui n'a pas connu le jour), mais dans les faits, elle est tombée en sommeil et est née à nouveau en 2015. Si tu veux nous comparer, prend les autres organismes nés récemment et tu verras qu'elles sont toutes aussi petites que nous, voire qu'elles ont plus de mal que nous.
Il y a 15 ans, déjà c'était plus simple car il y avait encore peu de projets, donc dès que l'un d'eux émergeait avec du code fonctionnel et commençait à se professionnaliser, les gens se ruaient dessus avec leur portefeuille ouvert. De nos jours, les projets florissent quotidiennement. Les gens donnent toujours, mais ils répartissent leurs dons. Regarde donc tous ces autres projets récents dans le Libre: ils ont tous autant de mal que nous.
En outre, même ces gros projets d'antan n'ont pas commencé avec les sommes de maintenant. Donc il faudrait nous comparer avec leur situation d'antan (probablement un peu meilleure que nous, car peu de projets à l'époque encore une fois, mais meilleure de très peu).
Voilà. Je pense qu'on peut conclure ici. Encore une fois, mes longues réponses ne sont ni des attaques ni des défenses (je ne me suis pas senti attaqué). Ce sont juste des explications de notre situation, et je le fais en détaillant un peu comment marchent les choses de mon point de vue (qui peut être erroné, mais en même temps, c'est ainsi que je le vis au quotidien, donc même si j'ai peut-être tort, j'ai du mal à m'en défaire). Et donc oui, on professionnalise le développement de GIMP et la réalisation d'un film libre (ce sont des faits; on a du mal, mais on y arrive en partie); mais non, je ne pense pas que cela peut passer par l'emploi de gens au marketing à notre stade (sauf s'ils veulent le faire bénévolement pour LILA, mais même là, on ne peut pas accepter n'importe qui juste parce qu'ils veulent, et surtout je peux pas aller les chercher: ils doivent proposer d'eux-même, c'est une partie de la définition du bénévolat).
Désolé. Je suis conscient que c'est pas facile de voir l'état d'esprit des gens à l'écrit, surtout avec un long pavé comme les miens. :P
Pour moi, vous êtes vraiment sur la bonne voie avec tout ce qui est mis en place ces dernières années, que ce soit avec Gimp ou The Marmot. J'espère que vous trouverez des renforts pour que ces financements puissent se débloquer :)
Merci. On pense aussi être sur la bonne voie, même si on est pas sûr que notre véhicule tiendra le coup jusqu'au bout parce que cette voie est un peu caillouteuse. Et oui on espère aussi qu'on trouvera du financement. ;-)
Si tu veux, et si tu es à Paris, je serais heureux d'en discuter autour d'un café (mon email traîne partout, notamment sur mes commits) et tu verras qu'il n'y avait pas méprise. Juste désaccord sur le process, mais sans aucun mauvais esprit. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Plus qu'une fondation, je pense que les gens attendent surtout une professionnalisation (même si tu préfères une bande de potes hippies :p)
Ben écoute d'un côté, on a une fondation (hypothétique) qui paieraient des salaires pour améliorer GIMP et de l'autre une association (non hypothétique, elle existe) qui paie des salaires pour améliorer GIMP. Mais le premier cas serait de la professionnalisation et le second une bande de potes hippies. Euh… Ce serait pas une nouvelle version du bon et du mauvais chasseur là? ;-)
Sérieusement c'est un peu triste. On a l'impression que vous vous attachez au nom. Parce qu'on n'a pas "GIMP" dans le nom, c'est soudainement pas "professionnel"? Ou alors je vois pas. Parce que soyons clair, c'est un peu la seule différence là.
accélération du développement
Je pense que peu de logiciels peuvent se targuer d'avoir un développement aussi intense que nous. Attention, je dis pas qu'y en a pas qui ont un développement encore plus actif. Je suis sûr que Firefox par exemple nous coiffe au poteau. Par contre comparons par exemple avec un logiciel tel que Blender.
Voyons le nombre de commits dans GIMP (master) depuis le début de l'année et depuis début 2017:
Voilà, GIMP a plus de 40% de commits en plus sur les 8 derniers mois. Ensuite si on remonte le temps, Blender gagne du terrain, on a à peu le même nombre de commits sur les 20 derniers mois et ça s'inverse en remontant plus loin. Notre activité n'a fait que s'accélérer depuis des années, continuellement. Je sais pas trop ce que tu veux de plus.
Et tout cela, avec en gros 3 core développeurs (Mitch, Ell et moi-même) qui faisons à peu près le quart des commits chacun (puis y a d'autres développeurs, certains plus réguliers que d'autres). Je crois qu'on n'a vraiment pas de quoi avoir honte de notre petite équipe. Peu peuvent se targuer d'une telle activité.
Comme tu le soulignes toi-même, c'est juste une histoire de perception (ou encore "a priori"). Un logiciel comme Blender, on va lire qu'ils sont méga actifs, etc. Mais pas GIMP? Ensuite cette perception n'est heureusement pas généralisée, car (comme je le dis dans l'article), notre image a vraiment changée et je ne lis plus personne dire que le développement de GIMP est lent. Tu es le premier que je lis ressortir cela depuis un bon moment. :P
Pour résumer, plus de pognon pour pouvoir faire plus de choses, puisque apparemment, les bénévoles compétents et motivés sur le long terme, ça ne court pas les rues.
Ben les employés compétents et motivés aussi, je t'assure. Je ne sais pas exactement ton champs d'activité (mais si tu traînes ici, les probabilités que ce soit quelque chose dans l'informatique sont grandes!), mais dans le développement logiciel, tu trouves aussi (c'est à dire comme dans tout métier) beaucoup d'incompétents. L'argent ne fait rien à l'affaire.
Et pour avoir eu aussi mes expériences professionnelles dans le développement logiciel en entreprise (comme on peut s'y attendre), laisse moi te dire que notre petite équipe de bénévoles "hippie" n'a vraiment rien à envier à tes supers employés qui seraient plus à même que nous d'offrir aux gens ce dont ils rêvent. Franchement j'ai rarement vu un tel regroupement de gens compétents que dans notre micro équipe (non seulement les 3 au cœur, mais aussi ceux qui bossent sur GEGL, ainsi que certains réguliers qui font pas tant de patchs, mais quand ils en font ou quand ils réagissent, tu te dis que tu aimerais bien les voir plus souvent!).
En conclusion, je voudrais boucler et revenir à ce que j'ai dit au début de ce commentaire: oui LILA est professionnelle. Et lever des fonds participatifs pour employer des développeurs est exactement ce que nous essayons de faire. Franchement avant de parler d'engager de nouveaux développeurs/designers, on aimerait bien pouvoir avoir au moins assez pour payer ceux qui contribuent actuellement et aimeraient bien en vivre (nous sommes 2: le mainteneur de GEGL et moi-même sur GIMP, voire 3 en comptant Aryeom qui de temps en temps fait des illustrations pour gimp.org, des icônes, des ateliers, ou autres, et surtout aide en donnant continuellement des retours pour améliorer GIMP et son interface en tant que professionnelle l'utilisant au quotidien; aucun de nous n'a actuellement assez pour financer un salaire minimum).
Je dois avouer avoir un peu du mal à comprendre. Beaucoup nous disent que si nous faisions des crowdfunding pour améliorer GIMP, ils donneraient. Mais la réalité, c'est qu'on le fait depuis environ 2 ans maintenant (et oui, c'est officiel, nos crowdfundings sont listés dans la page donation de GIMP). On a donc déjà professionnalisé GIMP depuis 2 ans. Il ne tient maintenant qu'à vous tous de nous permettre de ne pas abandonner en si bon chemin (parce qu'on y pense plutôt régulièrement malheureusement). :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Les fonds de GIMP ont toujours été gérés par la fondation GNOME. Cette annonce ne change absolument rien du tout. Mais vraiment rien.
Ensuite si on décide que cet argent peut aller en salaires, une partie peut éventuellement être donnée à LILA.
Encore une fois, relire mon commentaire. Je ne comprends pas pourquoi vous voulez absolument une "fondation" alors qu'on a déjà tout ce qu'il faut. C'est une obsession sur le nom?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
D'un autre côté, on parle de centraliens. S'ils doivent faire un emprunt, ils devraient pouvoir le rembourser assez vite avec un brut moyen de 52 000 € par an.
Cela implique que les étudiants doivent rentrer dans les cases. Si une personne décide de ne pas aller vers un boulot classique d'ingénieur centralien, et probablement avec un salaire moindre, alors il ne peut plus rembourser. Donc on le force à faire quelque chose de sa vie qu'il ne veut pas forcément.
Je ne dis pas cela au hasard. Il y a pas mal d'années par exemple, j'ai failli acheter un petit appart, pour lequel je me serais endetté pour des dizaines d'années et aurait été incapable de lâcher mon boulot d'ingénieur (sauf pour un autre, si possible avec le moins de vacances entre-deux). Puis je me suis ravisé et ai décidé que je préférais vivre bien. Par la suite, j'ai même démissionné (sans autre boulot en perspective), j'ai vagabondé, ai vécu dans plusieurs pays (en travaillant là-bas parfois, parfois non). Puis de nos jours, je fais du Logiciel Libre (pendant des années entièrement bénévolement) et je développe GIMP avec des salaires qui feraient rigoler (jaune) n'importe quel ingénieur (soyons clair, on parle même pas de salaire en sortie d'école, et de loin; mais vous êtes tous bienvenus pour aider à notre financement collaboratif si vous aimez GIMP ;p).
Mais globalement je suis heureux de ma vie, j'aime ce que je fais et mon but ultime n'est pas de rouler sur l'or (même si j'aimerais bien être bien payé, soyons clair; mais "vivre bien" passe en priorité).
Alors forcer les gens à prendre un prêt dès leurs premiers pas en tant qu'adulte signifie ne plus leur donner de choix sur ce qu'ils feront de leur vie. Ils doivent au plus vite marcher au pas. Ensuite certains, c'est exactement ce qu'ils veulent et ils sont très heureux avec cette vie. Mais pas tous.
Et la réponse éventuelle "ces personnes ne sont pas obligés d'aller en école d'ingénieur" n'est pas acceptable. Pourquoi serait-il interdit d'avoir de bonnes études d'ingénieur sans vouloir rentrer dans les cases professionnellement ni s'endetter? Tout ce que j'ai dit précédemment peut aussi s'appliquer à un ingénieur (comme à n'importe quel métier, donc n'importe quelles études).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Il y a tout de même une différence de processus avec la Blender Foundation. Ils mettent le logiciel en avant, alors que sur ce projet, je préfère mettre la création en avant. Le logiciel libre est pour moi simplement une évidence (tout logiciel devrait être logiciel libre), pas un but. :-)
Et ça veut aussi dire que nous pourrions aussi contribuer à d'autres logiciels, pas seulement à GIMP (ce que d'ailleurs je fais, même si effectivement à ce jour, GIMP seul est environ probablement la moitié de mes contributions).
Est-ce que tu penses qu'il serait possible d'envisager une telle structure pour GIMP ?
Il y a déjà plusieurs "problèmes" à un tel raisonnement. GIMP n'est à ce jour pas une entité du tout (pas une association, pas une entreprise, pas une fondation, rien d'enregistré). Nous avons un mainteneur, mais même là, cela reste une organisation extrêmement organique et qui arrive vraiment à s'auto-gérer (très bien en plus!) simplement par la bonne volonté et bienveillance des contributeurs principaux (franchement, c'est l'une des ententes les plus cools que j'ai connues dans le Libre, et c'est ça qui m'a fait rester). Si on doit citer un exemple typique de l'organisation "bazar" du Logiciel Libre, GIMP est probablement un des meilleurs exemples (voire l'un des seuls parmi les plus gros logiciels connus du Libre).
Or on aime tous cette ambiance, coordination et organisation bon-enfant, et sérieusement ça me ferait mal de pêter ça, en essayant d'y rajouter une structure plus rigide. Perso j'adore le fait que GIMP soit pas une entité définie, de même que j'aime aussi les organizations horizontales, les partenariats (genre SCOP en entreprises, un concept que j'aimerais bien faire un jour si je monte une boîte), bien plus que les hiérarchies.
Je pourrais essayer de le faire seul dans mon coin, par exemple en reformulant le but de notre association (LILA) pour en faire une GIMP Foundation, ou en créant une nouvelle entité, mais franchement cela pourrait être ressentie par les autres contributeurs (et probablement à raison) comme une sorte de coup d'état. Une prise de pouvoir par la création d'une entité dans notre coin qui utiliserait le nom GIMP alors que tous les autres sont cools avec l'organisation informelle actuelle. Franchement j'ai pas envie de ça. Je pense que la seule chose qui en ressortirait serait de ruiner le développement et les relations dans l'équipe GIMP. Et probablement cela ferait fuir les contributeurs (déjà qu'on n'est pas nombreux! Et notons que même si je me considère pas mauvais, je connais aussi mes limites; et je suis super heureux de coder aux côtés d'autres développeurs vraiment super doués; la dernière chose que je voudrais serait de les dégoûter de contribuer).
Aussi comme je le disais, nous on aime l'idée que notre but est de créer un film, des vidéos géniales pour Framasoft ou d'autres gens, même un jeu de société récemment pour une autre asso, etc. Le tout avec des logiciels libres que nous améliorons nous-même. Et non pas l'inverse: mettre l'accent sur un logiciel pour que d'autres utilisent. Donc je préfère LILA telle qu'elle est actuellement et n'ai pas vraiment envie qu'on en fasse une fondation GIMP.
Dernier point, soyons honnête un instant! Cette structure existe! C'est LILA! Bon je me contredis (exprès!), car je viens de dire juste à l'instant que nous ne sommes pas la fondation GIMP et ne souhaitons pas le devenir. Mais dans les faits, on développe GIMP et des projets autour. À ce jour, c'est plus ou moins 100% de ce que l'on fait. Si le besoin d'une telle structure, c'est d'avoir une entité officielle et enregistrée à laquelle donner, ou à laquelle se raccrocher de manière officielle, ben LILA fait parfaitement l'affaire et vous pouvez être sûr que votre argent est utilisée pour GIMP.
Maintenant cela peut changer. Peut-être que dans un an, 2 ou 10, on fera un projet en contribuant plutôt à Blender, ou Synfig, ou Inkscape (ou que sais-je encore). Et ce jour là, si ça ne convient plus, vous pourrez changer de crèmerie. Et surtout vous le verrez venir, et on l'annoncera en avance. Mais pour l'instant, on est ce qui se rapproche le plus d'une fondation GIMP. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je ne comprends pas pourquoi certains disent que Ghibli a libéré OpenToonz. Ce logiciel a été développé par son éditeur après un rachat d'entreprise. Cela n'a rien à voir avec une décision de Ghibli qui ne faisait qu'utiliser ce logiciel (fait qui a beaucoup été mis en avant pour promouvoir le logiciel certes), comme d'autres.
Quant à Cube, puisqu'ils font beaucoup de 3D, je sais que c'est surtout Blender qui les intéresse. J'ai un peu (rapidement) rencontré un des patrons dans leurs locaux y a quelques mois, et il a effectivement dit que Blender l'intéressait (sans que quiconque mette le sujet du libre ou de Blender en particulier sur la table, il en a parlé de lui-même en parlant des logiciels), principalement pour l'économie sur les licences. Il a aussi dit que ça prendrait probablement du temps pour y passer car les premières personnes à convaincre sont les réalisateurs (on rappelle qu'en animation, un réalisateur est un vrai technicien et il a aussi besoin de bien connaître les logiciels du pipeline) or ces derniers ont souvent leurs habitudes. Aussi il a dit qu'ils n'utiliseraient aucun des moteurs de rendu de Blender (pas même Cycles dont on parle beaucoup). Il a cité un autre moteur (dont je ne saurais plus dire le nom; probablement un moteur propriétaire d'ailleurs) en disant que les moteurs de Blender n'ont pas la qualité suffisante (d'après lui; perso, je ne saurais me prononcer).
Enfin perso, j'en ferais pas non plus une grosse news. Blender est déjà bien implanté dans le métier (même si clairement pas le n°1 non plus), on en entend régulièrement parler dans divers studios, voire certains l'utilisent effectivement déjà, Pôle Emploi finance des formations Blender, etc. En tous cas, c'est cool, mais rien de bien neuf. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Configurer avec le préfixe par défaut (/usr/local), et surtout installer en root est le meilleur moyen de pêter un jour son système. C'est fortement déconseillé.
De manière générale, il n'y a absolument aucune raison de faire quoi que ce soit avec les droits d'administrateur quand on compile un programme (bien sûr, hormis les quelques cas spéciaux de logiciels qui ont besoin de droits d'admin pour par exemple ajouter un setuid, ou logiciels très bas niveau, ou autre; je doute qu'emacs soit un de ces cas particuliers, sauf erreur), malgré les nombreux tutos qui pullulent sur le sujet et qui se recopient les uns les autres sans réfléchir.
En fait sous Linux, on peut (et on a toujours pu) installer des logiciels sans le moindre droit admin (encore une fois, sauf exceptions)!
Donc, déjà s'il y a une option générique des autotools à connaître, c'est --prefix qui permet de choisir un préfixe d'installation perso. Dans mon cas, je prends souvent $HOME/.local. Ainsi l'appel devient:
./configure --prefix=$HOME/.local/
Puis au moment de l'installation, un simple:
make install
Pas de sudo nécessaire! Vous avez tous les droits d'accès dans votre $HOME.
Bien sûr, il est fort probable que votre système ne met pas les variables d'environnements appropriés pour trouver un logiciel dans $HOME/.local (quoique j'ai déjà vu cela, ce préfixe est assez classique car il est parent de $XDG_DATA_HOME). Je conseille de rajouter cela dans votre ~./.bashrc:
Et quand bien même, ça serait assez absurde de nier le concept de «propriété intellectuelle»
Ben non, comme le prouve BAud et tant d'autres. On peut vouloir repenser l'affirmation qu'on peut être propriétaire de la représentation/utilisation d'une œuvre parce qu'on en est l'auteur (droits d'auteur), ou de l'implémentation d'une invention (brevets) ou d'un nom ou logo (marque), etc. C'est un débat classique de société. Il n'y a donc rien d'absurde.
Par contre, non il ne s'agit pas de nier l'existence de ce concept. Le concept existe, c'est concret (par définition s'il y a un terme pour nommer le concept!), et surtout il est dans la loi française (donc non seulement il existe philosophiquement, le concept existe aussi légalement). C'est un fait. D'où ma réponse à BAud. Mais vouloir en discuter la légitimité est tout à fait approprié et n'a rien d'absurde.
Note que je ne dis pas que j'en discute entièrement la légitimité moi-même. Je suis plus intéressé par faire des choses concrètes en utilisant le système en place (à l'heure actuelle, c'est pas comme si j'avais le pouvoir pour changer la loi!), notamment en utilisant des licences libres, que juste discuter. Mais clairement ça se discute.
Ça serait comme prétendre que les religions n'existent pas, ou que le créationnisme n'existe pas.
Euh… non pas du tout. Si tu veux vraiment faire ce genre de parallèle, à la limite c'est comme prétendre que Dieu n'existe pas (et encore! Je crois que tu mélanges des choux et des carottes pour aider ton propos avec un exemple assez absurde et surtout très trollifère. Tu arrives quand même à faire dériver une discussion sur la propriété intellectuelle vers le sujet beaucoup plus sensible de religion, c'est fort! :P). Personne ne dit que ces concepts/courants n'existent pas. Mais certains en discutent la légitimité, c'est tout.
Une discussion pourrait tourner autour de l'idée que la propriété intellectuelle pourrait ne pas exister légalement.
Perso je ne comprends pas cette possibilité que tu évoques. La propriété intellectuelle existe légalement (en France du moins, je ne vais pas prétendre connaître les textes de loi de tous les pays, et si tu parlais d'un autre pays, on a juste commencé la discussion sur un quiproquo! :P). C'est un fait, c'est écrit noir sur blanc dans la loi, avec ces mots exacts ("propriété intellectuelle"). Y a rien à discuter ou à mettre ou subjonctif.
Ensuite interpréter la définition légale du concept, si c'est ce que tu voulais dire, oui c'est faisable.
Mais sinon à part discuter la légitimité du concept (avec éventuellement l'espoir de changer un jour la loi pour les gens contre ce concept), je vois pas trop ce qu'il y a d'autre à discuter.
Au final, j'ai bien assez discuté sur le sujet. La propriété intellectuelle est nommée dans la loi, c'est tout ce que je voulais dire dans mon commentaire. Néanmoins on ne peut pas nier que plein de gens en discutent la légitimité, genre constamment. Pour moi y a rien d'absurde dedans, et surtout y a pas de réponse évidente sur un sujet si complexe (à la fois philosophique et sociétal)… en tous cas pas une réponse qu'on trouvera sur Linuxfr sur un commentaire de quelques mots dans un fil de discussion quelconque. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ta remarque était peut-être d'ordre philosophique. Dans ce cas là, j'ai rien dit!
Mais hormis les considérations philosophiques, selon la loi, la propriété intellectuelle existe bien malheureusement, puisque le code qui définit justement ce que sont le droit d'auteur, les marques, les brevets d'invention, etc. s'appelle le "Code de la propriété intellectuelle". :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
900 000 lignes de code, je trouve cela juste gigantesque (c'est des années de travail à temps plein).
Ok, comme quoi, un commentaire, c'est plus clair quand on utilise des phrases complètes. ;-)
C'est vrai que ça fait beaucoup (même si j'ai pas pour habitude de regarder le nombre de lignes qui changent et que le nombre de lignes peut monter assez rapidement avec le code "boilerplate, etc.).
Je me souviens plus exactement comment j'ai fait ces stats y a quelques jours, mais en essayant d'en refaire maintenant avec git diff, je trouve:
Le premier commit est le premier commit du 28 avril 2018 pour le port GTK+3, le second étant le premier commit du 20 mai (jour de sortie de GIMP 2.10.2). La différence de compte doit venir que j'ai pris un autre commit de fin (comme j'ai préparé la news en avance bien sûr, un plus vieux commit), mais globalement les chiffres restent similaires (je voulais vérifier au cas où j'ai fait une faute en copiant!).
Comme tu as éveillé tout de même mon esprit critique, j'ai regardé en détail le diff. Et tu as raison, c'est trop! En fait y a une suppression d'un SVG compté par git comme 872001 lignes supprimées à lui-seul! Clairement ça plombe les stats et c'est pas du code. On tombe à 50.000 lignes supprimées pour 10.000 insérées. C'est sûr, c'est pas pareil! :-)
Bon on reste à une insertion pour 5 suppression, mais c'est moins qu'une pour 100.
Merci de faire remarquer. C'est tout de suite mieux quand tu fais des commentaires avec du texte dedans, tu vois! :P
D'ailleurs si les admins de linuxfr veulent corriger, c'est avec plaisir!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
On peut pas résumer/lister ces limitations dans une bulle d'information.
Il faudrait que je fasse un journal pour en parler (c'est prévu), et éventuellement faire un lien depuis gimp.org.
Les sandbox, c'est aussi beaucoup une évolution des logiques de conception des logiciels.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est surtout le mainteneur qui déteste les commits de merge, et ceci dit, je suis assez d'accord dans le cas de GIMP.
En gros, le but principal d'un commit de merge, c'est essentiellement "garder l'historique". Un commit doit garder son hash à jamais pour pouvoir être toujours retrouvable, histoire de ne jamais casser des liens ou rendre des discussions sur un changement particulier incompréhensible (car tu ne peux plus retrouver le commit discuté si le hash a changé).
Ça a beaucoup de sens sur de très gros projets avec énormément de contributeurs, etc. et surtout avec des branches de longue haleine. Par exemple si la branche principale est celle du mainteneur et chaque "lieutenant" (ou sous/co-mainteneur) a des branches (voire un remote) à lui, etc. Dans un tel contexte, on veut faire en sorte que toutes ces branches publiques à vie indéterminée gardent leur historique pour garder toute la cohérence.
Dans un projet comme GIMP avec 3 ou 4 développeurs permanents (et pas mal de gens externes qui font juste un patch par ci par là), qui bossent directement sur la branche master, ça a beaucoup moins d'importance. Quand on fait des branches de fonctionnalités, en général, on peut souvent juste les supprimer après coup, histoire de faire un peu le ménage. Une fois mergées, elles ne sont jamais retouchées. Et de toutes façons, même quand elles sont encore actives, nos branches ont en général quasi qu'un seul développeur (sauf à la toute fin, quand une revue est nécessaire et que quelques corrections sont faites éventuellement).
Dans ce cas, le seul intérêt du commit de merge est quasi complètement annihilé. Par contre ses défauts sont toujours là, et assez énormes: les commits de merge rendent un historique de commits vraiment illisibles. Je sais pas si tu as vraiment vu des arbres de commits (en vue non-linéaire) de gros dépôts, et notamment lorsqu'ils ont mergés des branches qui contenaient des dizaines de commits sur plusieurs mois. C'est juste une source de mal de tête.
Et je parle même pas de la vue linéaire (celle par défaut d'un git log) qui est rendue totalement inutile dans ce cas.
Dans notre cas hypothétique d'un gros projet dont la branche principale est quasi jamais développée directement et ne sert qu'à merger des branches publiques (qui elles accueillent du développement), c'est encore gérable. Mais un projet avec du développement quotidien et des commits de merge, c'est vraiment assez horrible.
Personnellement je ne serais pas contre des commits de merge sur certaines fonctionnalités de longue haleine qui ont nécessité des semaines ou mois sur une branche à part. Mais le monstre créé par les github/gitlab qui te font des commits de merge de partout pour un rien (genre: un patch de typo? Hop commit de merge!), c'est une aberration et surtout un abus complet du système et de la logique de git.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: dll hell
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 10.
Déjà un peu d'explication du problème pour bien comprendre. Windows cherche les DLLs dans cet ordre:
Pour le binaire principal
gimp-2-10, c'est facile car il suffit de mettre toutes nos DLLs dans le même répertoire$PREFIX/bin/. Elles seront toujours trouvées en premier.Le problème est pour les plug-ins qui sont dans
$PREFIX/lib/gimp/2.0/plug-ins/et lorsque ces plug-ins souhaitent utiliser certaines des bibliothèques livrées avec GIMP (qui sont donc dans$PREFIX/bin/).On pourrait simplement mettre les librairies à côté de chaque plug-in, mais cela signifierait dupliquer les bibliothèques un certain nombre de fois. Et en plus ça ne permettrait plus aux plug-ins tiers de profiter des biblios livrées. Donc ce n'est pas acceptable.
À la base, on rajoutait donc
$PREFIX/binau début duPATH(qui est spécifié dans un script de lancement). Mais si jamais une application installe une DLL (que nous utilisons, mais dans une version incompatible) dans un répertoire système, alors cette DLL est trouvée avant et les ennuis commencent.Une autre solution à laquelle je pensais est de jouer avec le répertoire courant (le faire pointer sur
$PREFIX/bin) mais il se trouve que siSafeDllSearchModeest activé (apparemment une valeur de la base de registre), le répertoire courant est soudainement cherché après les répertoires système aussi! Donc ça marcherait plus (enfin surtout ça dépendrait de la configuration de l'OS).La solution est donc d'utiliser
SetDllDirectoryW()pour donner la priorité à$PREFIX/bin, et pour être précis le mettre entre le répertoire du binaire (permettant aux plug-ins de bypasser nos biblios au besoin) et les répertoires système. C'est donc une solution au niveau du code.Un cas supplémentaire que nous avons corrigé dans 2.10.6 fut les plug-ins 32-bit lancé dans un environnement 64-bit. Dans ce cas, on doit leur donner un répertoire différent avec des versions 32-bit de nos bibliothèques (on le met dans
$PREFIX/32/binpar défaut, mais j'ai mis un flag pour changer ce répertoire à la compilation). Je détecte donc le bitness d'un plug-in avant de le lancer et lui assigne le bon répertoire de bibliothèques avecSetDllDirectoryW().Un nouveau cas dont j'ai récemment pris connaissance (et pas encore corrigé) est les plug-ins scripts lancés par un interpréteur 32-bit sur environnement 64-bit (si le script utilise des bibliothèques compilées). Dans ce cas, on devra détecter le bitness de l'interpréteur.
Par exemple notre installeur embarque seulement Python en 32-bit (je ne suis pas sûr pourquoi). Donc des scripts python un peu complexe qui utilise des biblios C risquent de ne pas fonctionner.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Soutenir Gimp
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 10. Dernière modification le 30 août 2018 à 12:44.
Ce projet tiers est ce qui permet de contribuer à GIMP et a fait de moi l'un des plus gros développeurs de GIMP ces dernières années (même le plus gros selon le décompte).
C'est simple, sans ZeMarmot, pas de GIMP. Je contribuerai alors sûrement à d'autres logiciels libres, selon mes autres besoins, mais je n'ai pas besoin de GIMP personnellement plus que ça (enfin régulièrement, je découpe, redresse, rend plus net, etc. des photos; mais pour cette utilisation basique, GIMP est déjà largement au niveau). Là on en a vraiment besoin, dans un projet professionnel, au quotidien 8h par jour.
(0) On a besoin qu'il soit stable. Quand on faisait les premiers tests avec Aryeom Han, GIMP crashait pour un rien (c'était vers 2012). Ça foutait la honte. Mes premières années de contribution, j'ai corrigé beaucoup de crashs (de mémoire, y en avait en utilisant une tablette graphique; y en avait aussi des supers mauvais lorsqu'on utilisait un IME, en particulier avec le coréen, dans l'outil texte, et plein d'autres dont je me souviens même plus) et autres problèmes de stabilité. Bon j'en corrige encore régulièrement, mais GIMP est devenu beaucoup plus stable.
(1) Toujours dans la recherche de stabilité, on a besoin de pouvoir aisément débugger et parer aux problèmes (qui arrivent sur tous logiciels même les plus stables). Donc j'ai implémenté une sauvegarde des images au moment du crash (pour ces bugs survivants qu'on n'a pas encore corrigés!), et GIMP propose maintenant au lancement suivant de tenter une récupération des images qui étaient en cours d'édition, ainsi qu'un système de débug qui génère automatiquement des backtraces, non seulement pour les crashs, mais aussi utilisables lors de WARNING et CRITICAL en cours d'utilisation (permet d'améliorer le logiciel en découvrant des bugs plus subtils). C'est l'une de mes fonctionnalités fétiches. Le nombre de bug qu'on a pu corriger depuis que j'ai implémenté cette fonctionnalité est impressionnant. Corriger des bugs est devenu simple, et les gens nous envoient désormais des rapports de bugs utiles, même lorsqu'ils ont aucune idée de ce qu'il s'est passé, qu'ils savent pas du tout parler anglais ni écrire des rapports de bug bien formés.
(2) On rajoute des fonctionnalités. Dernièrement je travaille beaucoup sur tous les détails pour les écrans haute densité de pixel (l'écran principal de travail d'Aryeom ne l'est pas pourtant, mais je sais qu'on y viendra; autant préparer GIMP en amont). Le système d'extension indiqué plus haut bien sûr me semble important. Nous aussi on utilise quelques plug-ins, mais très peu. Franchement c'est impossible de savoir ce qui existe et ce en quoi on peut faire confiance. Et surtout chercher, installer et faire marcher des vieux plug-ins peut être une vraie galère (et pourtant je suis développeur, c'est dire!).
Dans les quelques années passées, j'ai été responsable de plusieurs autres fonctionnalités, et je travaille à d'autres fonctionnalités encore (comme l'animation, comme on sait ici).
(3) On fait de la revue de code. Ça paraît bien moins sexy, mais c'est primordial. L'histoire de GIMP est parsemée de fonctionnalités sympas qui ont été perdues car personne n'a eu le temps de les vérifier. Je ne jette la pierre à personne: ça prend un temps fou. Dans cette sortie par exemple, l'écriture verticale n'aurait probablement jamais été intégré sans moi (je suis allé chercher le contributeur, j'ai fait la revue, les tests, les commentaires sur chacune de ses modifications; en tout j'y ai passé quelques heures).
Même le Marathi, j'ai vu un email perdu sur la liste de discussion des traducteurs auquel personne ne répondait; le problème est que cette langue n'avait plus de coordinateurs. J'ai donc essayé de relancer à la place des traducteurs (qui allait sûrement abandonner à un moment donné) et de leur donner espoir pour ne pas les décevoir (un espoir qui a abouti!).
Le redressement horizontal, j'ai retrouvé un vieux patch perdu dans le bugtracker et très basique. J'ai fait de la revue, retravaillé au dessus (car il n'était pas vraiment utilisable en l'état); Ell a fait de même ensuite. Et maintenant ça fait une super fonctionnalité.
Dans le passé, je me souviens bien de la recherche d'action (une de mes fonctionnalités préférées!). J'y ai passé un temps considérable. Le patch était cool, mais écrit par des étudiants. J'y ai passé de très nombreuses heures à corriger ce qui devait l'être, à rendre la fonctionnalité vraiment utilisable simplement, et à l'améliorer énormément. Maintenant je pourrais pas faire sans!
Pour info, dans GIMP, on a des règles stricts et du code de très bonne qualité globalement (bien sûr plus localement, on trouve beaucoup d'horreurs ici et là, comme dans tout gros code). Donc la revue est primordiale. On fait pas comme certains logiciels qui acceptent tout et n'importe quoi.
(4) On fait évoluer la politique interne. Je suis celui notamment qui a poussé depuis plusieurs années (tous les ans, à chaque fois qu'on se rencontrait au Libre Graphics Meeting) pour une nouvelle politique de sortie permettant de sortir des versions macros avec de nouvelles fonctionnalités (plutôt qu'attendre 6 ans encore pour une sortie majeure!). Et voilà, maintenant tous les mois, GIMP sort avec des fonctionnalités cool. Les gens se disent maintenant que GIMP est super actif, et on se met à avoir plus de contributions (j'ai l'impression; mais ça peut aussi être simplement car on a sorti 2.10, ou autres raisons).
(5) On a créé et on maintient le flatpak pour que les linuxiens aient GIMP facilement et rapidement à chaque sortie (GIMP est maintenant dispo sous Linux à chaque sortie avant toutes les autres plateformes!).
Et sûrement plein d'autres choses.
Ensuite soyons clair: je ne souhaite pas mettre tous les éclairages sur ZeMarmot uniquement. En particulier le mainteneur, Mitch, fait un travail de dingue, connaît le code de GIMP et ses rouages bien mieux que moi. Sans parler de Ell, un alien venu d'ailleurs, qui nous optimise GIMP aux petits oignons (avec du code d'excellente qualité) depuis qu'il est arrivé. Je ne suis pas seul (heureusement!), et on a tous les 3 une grosse part dans le succès de GIMP.
Mais clairement je ne pense pas que ce soit exagéré d'affirmer que le projet ZeMarmot a vraiment contribué largement à propulser GIMP dans une nouvelle ère. On travaille sur GIMP pour un vrai projet, au quotidien (oui je me répète) et ça vaut énormément de contributions aléatoires sans but. C'est un peu une symbiose de l'artiste et des outils. Chacun a besoin de l'autre.
Si avec cela, ce n'est pas suffisant, alors je ne sais pas ce qui l'est. Je rappelle qu'on est officiellement associé à GIMP d'ailleurs (bien sûr même! Je suis un dév majeur). Même le site web gimp.org suggère de donner directement à ZeMarmot sur la page donation, ainsi que dans ses news régulières (comme la dernière news dont cette dépêche sur Linuxfr est plus ou moins une traduction un peu retravaillée). J'aurais du mal à voir comment ça pourrait être plus limpide. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Soutenir Gimp
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 5.
On sait pas trop non plus. J'ai aussi vu passer des trucs vite fait, mais rien qui dit clairement "c'est bon, tout va bien". Ils font pas beaucoup de communications, c'est dommage.
J'aime beaucoup Liberapay, mais tant qu'on n'a pas de message clair comme quoi ils sont à nouveau dans la course, on peut pas vraiment donner le lien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 5. Dernière modification le 23 août 2018 à 18:39.
Tu parles du fait que c'est de la gestion d'extension dans GIMP? Si oui, bien sûr que là on parle de gestion (c'est même le titre), mais il s'agit du fait d'installer, désinstaller, mettre à jour et afficher des infos sur des extensions. C'est la partie côté cliente.
Ça veut pas dire qu'on gère l'extension au sens de vraiment s'en occuper. Si elle est bourrée de bugs, si elle marche pas même, c'est pas notre problème au delà de fournir des outils (pas immédiatement, mais probablement rapidement) pour que les gens puissent indiquer une extension qui fonctionne ou pas sur telle ou telle version de GIMP. Et si l'extension n'est pas maintenue, on ne s'en occupera pas plus.
Je dirais que c'est notre problème si on découvre des malware et là oui, on intervient et on vire l'extension. À ce moment, quand il y a intention malfaisante évidente (ou grosse faille de sécurité très dangereuse), il est évidemment de notre responsabilité de réagir. Mais ça s'arrête là. C'est en ce sens là qu'on ne gère pas les extensions (côté serveur) au delà de proposer aux gens de les héberger.
Les données inertes (brosses, images splash, thèmes, icônes, dégradés, etc.) ne subiront en effet pas de revue préalable, contrairement aux données exécutées (plug-ins) qui doivent être évidemment validées avant d'être diffusées.
Ensuite bien sûr que des vecteurs d'attaques peuvent exister avec des données inertes. Cela a toujours existé et existera toujours. On a tous entendu parler de failles permettant d'exécuter du code caché dans des images par exemple.
Néanmoins cela n'est pas un comportement normal, et ainsi dire "On peut voir le chargement d'un fichier comme une exécution d'un programme dans une sandbox" est faux, en tous cas pour le type de fichiers que tu cites (brosses) ou que je cite (images) [bien sûr, il existe des fichiers avec du code fait pour être exécutés, comme les fameuses macros de traitement de texte; de tels fichiers doivent donc être considérés comme du code]. Donc non, charger une bosse ou une image n'est pas la même chose qu'exécuter un programme. Ce sont des données inertes faites pour une utilisation donnée, pas pour exécuter du code tiers. Quand cela arrive, c'est un comportement anormal, autrement dit un bug (le plus souvent dans le logiciel, parfois dans le format lui-même) et qui doit alors être corrigé.
Aussi cela n'a rien à voir avec les extensions. Ce type de bug, quand il existe, existerait déjà dans GIMP et pourrait déjà se produire. Les extensions ne sont qu'un conteneur supplémentaire (ajoutant un peu de sémantique au contenu, indiquant de quoi il s'agit, un nom, une description, des liens annexes, une version, etc.).
Les haters ont toujours existé et existeront toujours. Je le sais bien, je parle moi-même régulièrement sur Linuxfr de cela. Soyons clair, ça me touche et c'est dur. Mais je ne vois pas en quoi faire ou non des extensions pourrait changer quoi que ce soit à cela.
En fait par rapport aux comportements inadéquats, ma politique perso est de rester neutre (si possible, parfois c'est dur de tenir) et d'expliquer aux gens justement ce que je disais: GIMP est un logiciel libre, le logiciel libre, ça ne marche pas comme ils semblent le penser. En plus on n'est pas une entreprise, et on développe de façon volontaire. Et non, on ne réagit pas bien aux menaces et insultes. Par contre on est heureux d'aider les gens agréables, et tout ce qu'on demande, c'est que ces gens comprennent aussi ce qu'il en est, et qu'on contribue principalement bénévolement, souvent sur du temps libre.
Eh ben, tu me croiras peut-être pas, mais être clair (et poli) désamorce pas mal de situations. Les gens se rendent compte qu'ils ont un peu été des malotrus, se calment, parfois même (ça arrive!) s'excusent.
Ensuite oui, ça n'est pas du 100%. Et certains sont juste là pour haïr, comme je disais. On ne peut rien pour cela. Mais encore une fois, je vois pas le rapport avec les extensions. Ces personnes trouveront de quoi redire pour chaque nouvelle fonctionnalité qu'on apportera. On va quand même pas s'arrêter d'améliorer nos logiciels pour ces gens là! En tous cas, perso, c'est pas pour eux que je développe. :-)
Je crois que tu cherches des problèmes là où y en a pas. :-)
Pourquoi qui que ce soit jetterait l'éponge pour quelques aigris? Si ça devait arriver, crois moi, ça serait arrivé y a trèèèès longtemps (comme tout gros logiciel connu, on collectionne quelques aigris).
Au pire du pire, si vraiment ça se passait super mal, on pourra toujours arrêter notre système d'extensions tiers (et n'héberger que nos propres extensions, voire un choix très restreint d'extensions sélectionnées au cas par cas, comme quelqu'un le propose plus haut). Perso je trouverais cela un peu dommage, mais si on devait en arriver là, c'est pas la mort.
Soyons clair, je ne pense pas qu'on en arrivera là. Je vois aucune raison à cela.
Ah oui, et:
Encore une fois, du vocabulaire de startup hipster. On s'en fout du "bad buzz". Je dirais même qu'on vit dans un monde où cela n'existe pas. Il y a des gens sympas, des gens moins sympas, ça s'arrête là. Si ce prétendu grand méchant bad buzz devait avoir eu raison de nous, ça serait arrivé y a très longtemps.
Merci beaucoup de t'inquiéter pour nous.
Je pense perso que tu te fais du mouron pour rien. :P
Si le type de problème dont tu parles devait arriver, je pense pas que ce soit parce qu'on ait ajouté un système de gestion d'extension dans GIMP. Ahahahah!
Sur ce, j'arrête de répondre sur cette news. J'ai un peu l'impression de trop l'accaparer en hors-sujet là, alors que c'est censé parler de ce super logiciel qu'est G'Mic. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 10.
Salut,
Nos installeurs contiennent la version 32 et 64-bit et installent la version appropriée. C'est écrit juste sous le bouton de téléchargement. Donc prends simplement l'installeur unique et ça te mettra la bonne version.
Ça oui par contre. C'est pas qu'on veut pas prendre en charge de plus vieux Windows, mais on n'a quasi aucun dév Windows (approximativement 0) alors on fait ce qu'on peut. Prendre en charge de vieilles versions veut dire plus de boulot car on doit contourner des problèmes de manières plus compliquées (même si des versions récentes ont peut-être amené des solutions simples).
Notre ligne directrice pour savoir si on prend en charge un OS (Windows ou macOS), c'est que cette version de l'OS doit au moins être encore pris en charge par son éditeur. Windows XP, y a plus de support depuis avril 2014 (d'après Wikipédia) et on parle quand même d'un système sorti en 2001, soit y a 17 ans!
Il est peut-être temps de mettre à jour. Et si le matériel est juste trop ancien, on peut mettre un Linux avec bureau léger. Ou si vraiment on est nostalgique des vieilles années et qu'on veut garder l'OS d'époque absolument (faire attention à l'accès internet, etc. dans ce cas), ben on prend sur soi et on garde aussi les vieux logiciels (y compris GIMP 2.8). :-)
Enfin bon, tout cela pour dire qu'il n'y a pas vraiment de solutions miracle, désolé. On peut pas prendre en charge indéfiniment un système, surtout si même son éditeur ne veut plus le prendre en charge. Ce serait vraiment se tirer une balle dans le pied.
Tout est possible. Ensuite je crois que la plupart des gens qui compilent GIMP pour Windows le font depuis un Linux (même notre build officiel est cross-compilé, il me semble). Donc ce sera clairement cela le plus simple.
Et je suis pas certain que ce build fonctionnera de toutes façons. Ne pas prendre en charge Windows XP, ça veut surtout dire qu'on a peut-être (probablement) utilisé des APIs Windows qui n'existaient pas encore dans XP. Donc tu te retrouveras à devoir patcher le code en fonction des parties qui poseront problème. Si tu le fais sans perte de fonctionnalité ni rendre le code surcompliqué (et avec un code propre), on veut bien le patch (on n'est pas absolument contre Windows XP, on ne le prend pas officiellement en charge, c'est tout).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 6.
On ne les gèrera pas. On les hébergera. Mais oui tu as raison quand même qu'on aura notre part de responsabilité.
Même si GIMP lançait des sandbox, la revue et compilation doivent être faites de notre côté. Héberger aveuglément un binaire d'inconnus complets est une aberration.
C'est la raison pour laquelle les plug-ins compilés ne seront pas acceptés tant qu'on n'aura pas l'infra. Certains bénéficieront d'exception évidente comme G'Mic. C'est expliqué dans mon article.
Je ne prévois pas de gérer le site. Je suis développeur pas animateur de communautés. Nous avons une très grosse communauté avec des gens très actifs et même pas mal plutôt techniques. Des gens comme Pat David et Elle Stone seront parfaitement capables de gérer le quotidien (et de sélectionner les futur modérateurs si le contenu grossit vite).
Aussi on pourra y aller lentement. Si les gens sont pas contents du temps de revue, ce n'est pas notre problème. L'un des énormes avantages que l'on a est qu'on n'essaie pas de faire du business. Nos actions ne sont pas dirigées par des contraintes économiques. Ça rend GIMP très résistant aux problèmes car personne ne peut nous forcer à rien ni nous presser.
Bon j'arrête là. Cette dépêche est au sujet de G'Mic pas de GIMP! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 10.
Non ce n'est pas envisageable. De même que notre installeur Windows ne contient pas G'Mic (pas plus que tout autre plug-in tiers), ni notre DMG pour macOS.
Les builds officiels de GIMP ne contiennent (et ne contiendront toujours) que les plug-ins core de GIMP, c'est à dire ceux maintenus par les développeurs de GIMP. On a déjà bien suffisamment de boulot (avec très peu de développeurs) pour ne pas non plus se donner plus de travail. En outre si quelqu'un fournit un paquet, il est de-facto responsable de son contenu (or on ne développe/maintient pas G'Mic). Pour G'Mic, c'est un logiciel suffisamment complexe et élaborée pour qu'on se rende bien compte que si David venait à arrêter demain (on touche du bois pour que ça ne soit pas le cas!), on ne serait pas à même de le maintenir à sa juste valeur.
Donc non, on ne peut pas.
De même que David, je pense qu'il préfère garder l'indépendance dans ses sorties, etc. et ne pas dépendre de nos choix de sortie.
La tendance est plus à la création d'un système d'extension (voir ma news pour GIMP 2.10.6 qui devrait être publiée d'ici quelques jours) qui permettra d'installer facilement G'Mic et autres plug-ins, tout en laissant les développeurs de ces plug-ins en garder la main complète. Tout le monde y gagne. Et je sais, de source sûre, que David aime l'idée. ;-)
D'ailleurs une fois que cela sera en place, il est même possible que certains des plug-ins core actuels puissent devenir des extensions à leur tour (toujours maintenus par nous, mais avec un rythme de développement parallèle), ce qui permettrait des menus moins touffus de fonctions que peu de monde utilisent par exemple. À voir…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 5.
Oui c'est malheureusement un des trucs (le flatpak de GIMP et les plug-ins) sur lesquels il faudrait bosser plus. :-/
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Aperçu
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 10.
Perso je pense que la prévisu sur canevas serait super utile, même pour les traitements lents.
La prévisualisation n'a pas à être activée par défaut. ;-)
GIMP donne aussi la priorité au rendu de la partie visible à l'écran, et le mipmapping aide aussi beaucoup si un zoom (avant ou arrière) est fait. Et je sens que les choses vont s'améliorer encore dans le futur pour optimiser la sensation de fluidité (ou du moins de pas avoir une expérience trop désagréable), même avec des traitements lents.
Ce sera clairement utile pour l'édition non-destructive également. Faire un changement dans les paramètres d'un effet peut te prendre 10 minutes, mais dans tous les cas, tu devras le refaire (ton effet). Dans le cas de l'édition non destructive, au moins tu pourras voir les paramètres utilisés précédemment et repartir de là. Dans le cas de l'édition destructive, tu as intérêt à avoir bien gardé une copie du calque d'origine et tu ne sais même pas l'ensemble des traitements faits, et avec quels paramètres, à part si tu les as notés bien consciencieusement (ce que certains font dans le nom du calque par exemple).
Pour moi, il n'y a rien d'équivoque là. Mais je crois qu'on a déjà eu cette discussion et qu'on pourra encore l'avoir à l'avenir. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Positive attitude
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 4. Dernière modification le 15 août 2018 à 18:42.
Je ne contribue que depuis (relativement) récemment, c'est à dire depuis 2012. Mais il paraît que certains des anciens contributeurs de l'époque d'avant n'étaient pas très cool, voire peut-être même un peu toxique. Mais ce n'est que du "on dit" car je ne les ai pas connus.
En tous cas, de nos jours, ce n'est plus le cas. :-)
On a un peu mis en pause pour diverses raisons. Déjà y a le côté technique. Le logiciel de streaming (libre) faisait quand même beaucoup souffler la machine (qui a déjà beaucoup à faire quand on fait de l'animation), voire était plutôt instable (cela nécessite OpenGL 3.2, ce qui veut dire qu'on doit installer les pilotes Nvidia proprio, et même là, ce n'est pas parfait). Le pire n'est pas seulement que ça plantait parfois, mais qu'il arrivait à faire freezer la session graphique de temps en temps. OBS Studio est cependant très connu et une référence a priori chez les gens qui font du live, même s'ils savent pas que c'est libre. Y a peut-être quelque chose à configurer mieux. Et aussi j'ai cru comprendre que la version Linux est moins stable de manière générale. À voir…
Ensuite oui, y avait pas tant de monde, et on se disait que ça valait pas forcément le coup.
Mais surtout, Aryeom a eu une petite période de blues ces derniers mois (je l'ai déjà dit, l'un comme l'autre, on se pose beaucoup de questions; on nous dit constamment que GIMP peut lever beaucoup de financement participatif, mais dans les faits, notre financement est faible), voire un petit burnout. Donc elle a préféré continuer à travailler sans les lives. Mais là je lui ai montré ton message, et elle se dit qu'il faut peut-être les recommencer. On verra!
P.S.: ne pas hésiter à laisser un message si on reprend les lives. Ça fait toujours plaisir et ça donne moins l'impression de faire un direct dans le vide. Faut pas donner tous les mercis qu'à moi. Y aurait rien de tout cela sans Aryeom non plus.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Fréquence de commits un peu exagérée
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 5. Dernière modification le 09 août 2018 à 23:18.
Je ne me souviens plus du calcul exact de l'époque mais je peux en refaire un.
En gros, je regarderais les commits faits entre GIMP 2.10.2 et 2.10.4, et ce, sur
master, car c'est là où se passe vraiment le développement (pas sur la branchegimp-2-10en particulier qui ne contient que les backports pour la série stable).Sur master, y a un tag
GIMP_2_10_2mais pasGIMP_2_10_4car on a créé la branchegimp-2-10justement à la sortie de GIMP 2.10.2 (donc c'est là où les 2 branches ont commencé à diverger). Pour le commit d'arrêt, je vais donc prendre un commit qui correspond à la date de sortie de GIMP 2.10.4, soit le 2018-07-04. Je prends le dernier commit à cette date. Note que ce n'est probablement pas le calcul que j'avais fait à l'époque, car j'imagine que j'avais prisHEADqui était sûrement différent à l'époque (soit un peu avant, soit un peu après la sortie. Je ne suis pas sûr quand j'ai démarré cette dépêche collaborative). Quoiqu'il en soit, voyons le nombre de commits:Comme il s'agit d'une période de 45 jours, je fais une moyenne, soit:
972 / 45 ≈ 21,6. Voilà (avec un arrondi, ça fait 22 ;p).Ensuite soyons clair: GIMP 2.10.2 est le moment où on a divergé vers le port GTK+3, comme je viens de le dire, donc ça veut notamment dire qu'on a mergé tout le travail fait sur GTK+3 (dont la majorité avait été faite ce même avril/mai, après la sortie de GIMP 2.10.0!) d'un seul coup. En un sens, ça a clairement boosté les statistiques. D'un autre côté, tant qu'on ne merge pas une branche de fonctionnalité, elle ne rentre dans aucune statistique. Faut bien qu'elle le rentre un jour (de même que j'ai des dizaines de commits qui attendent dans des branches de fonctionnalité en cours, et un jour, je les verserai dans
masterd'un coup, mais en attendant, c'est comme si ils n'existaient pas). De toutes façons, il y avait clairement un moment, qui correspond à la sortie de GIMP 2.10.0 où on a vraiment eu un gros pic de contributions.Si maintenant tu remontes plus loin, par exemple le début d'année, comme tu le proposes, on a une moyenne à 11 commits par jours:
De manière générale, il y a forcément des hauts et des bas dans le développement. Surtout que comme on est 3 à faire la plupart des commits, forcément il suffit qu'il y ait une période où l'un de nous est peu actif pour que les stats baissent (par exemple pour le mainteneur, c'est souvent les fins d'année où il a moins le temps de contribuer car il a un commerce), de même qu'y a des périodes où tout le monde s'active. Quand je dis qu'on est très actif depuis des années, ça veut pas dire qu'y un taux constant de contributions à tout moment (ce serait pas humain!). D'ailleurs, ailleurs dans un commentaire, je dis même que notre développement s'accélère au contraire (ce qui ne veut pas dire que ça ne va pas se calmer à un moment, et puis de toutes façons, il y a des limites humaines à notre rythme de contributions!). Voilà, donc en gros, faut pas non plus s'attacher au mot près. Je donnais les stats entre 2.10.2 et 2.10.4, qui étaient effectivement de 22 commits par jour en comptant dans git, et c'était effectivement un très gros pic.
Enfin les stats, c'est aussi beaucoup du "marketing", soyons clair. De toutes façons, on peut faire dire beaucoup de choses aux nombres, on le sait tous. Rien que le choix d'unités est sujet à critique. Un commit, est-ce vraiment un critère adéquat? Faut-il compter le nombre de lignes à la place? Compte-t-on alors les lignes de commentaires (important aussi) ou juste le code pur et dur? Et qu'en est-il de ceux qui ont un code plus concis ou plus élagué (par exemple déclaration et définition sur des lignes distinctes, etc.)? Comment compte-t-on le temps de recherche, diagnostic, lecture de docs? Le temps pris pour des choses (importantes) autre que du code (écriture de news, docs, etc.), même? D'ailleurs peut-on même simplement compter le temps passé par les contributeurs pour GIMP (réponse directe: non, c'est du logiciel libre, on sait pas combien de temps passe chacun), et alors qu'en est-il des gens simplement plus efficaces que d'autres? Etc. Etc. Etc.
Ma conclusion, c'est que ce sont des stats. Les miennes étaient vraies (comme montrées plus haut) car notre branche master a réellement 22 commits par jour entre GIMP_2_10_2 et la sortie de 2.10.4. Ensuite ça vaut ce que ça vaut (pas grand chose, ou beaucoup, c'est selon).
Là où je voulais en venir avec ces stats, c'est que c'est du développement vraiment très actif. Et d'ailleurs tu es d'accord sur ce point. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: avec insistance
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 2.
Va pas donner de mauvaises idées aux gens! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP Fundation ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 5.
Ah je pensais que tu parlais du développement en cours, parce qu'on nous fait souvent la remarque qu'on devrait sauter direct à GTK+4. On y a pensé nous-même d'ailleurs (on a une news vieille d'avant même la sortie de 2.10 où on évoque la possibilité) mais on a décidé que ce n'est pas une bonne idée (pas avant stabilisation du moins).
Ahahah. Qui sait?! Moi j'en sais rien en tous cas. On y travaille, mais on donne pas de dates. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP Fundation ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 9. Dernière modification le 05 août 2018 à 10:57.
T'inquiètes, je n'avais pas pris mal ton commentaire. J'essayais simplement d'y répondre pertinemment. Le fait est que quand on fait quelque chose similaire à notre projet, on semble se récolter tous les conseils du monde. Ce n'est pas mal, soyons clair. C'est un peu fatigant, mais ce n'est pas mal. D'ailleurs je suis sûrement aussi le premier à donner des conseils à d'autres quand ils se lancent par exemple en indépendant (je ne suis d'ailleurs pas certains si mes conseils sont si pertinents et si je contribue pas à fatiguer ces gens, même s'ils ne me le disent pas par politesse).
Le truc, c'est aussi que beaucoup de ces conseils sont des trucs que je sais, ou même que je sais ne pas marcher, voire souvent que j'ai déjà essayé maintes fois. Je pourrais te citer toute une liste des classiques (mais je vais pas le faire sinon rallonger encore plus le commentaire).
Dans ce fil, on me propose de faire une fondation GIMP (je l'ai entendu 20 fois), qu'il faut plus d'argent (captain Obvious), que beaucoup attendent les fonctionnalités X ou Y (on accepte les patchs!). D'ailleurs la pertinence de ta liste de fonctionnalités est vraiment sujette à question. Genre quand tu me dis:
Ben… non GTK+3 n'est pas obsolète. C'est la version à jour de GTK+. Non, on ne va pas commencer à travailler sur une version "mouvante", pas sortie et donc qui va constamment casser son API. On a bien assez de boulot (et comme tu le notes, on est peu nombreux). Travailler sur une version de développement serait comme se tirer une balle dans le pieds pour être sûr que GIMP 3 ne sorte jamais (ou dans 10 ans) et qu'on ait constamment à corriger notre code (comme si on n'avait pas assez de travail!). Surtout qu'on parle de GIMP, pas d'une petite application mono-fonctionnalité de 10 000 lignes de code (qui elle, oui, peut se permettre des changements dans son toolkit, éventuellement… enfin si elle ne prévoit pas de sortir d'ici quelques années!).
Nous avons une règle au sujet de nos dépendances pour la branche master: il faut qu'elle soit dispo dans Debian Testing. Cela la rend suffisamment récente pour travailler avec des dépendances qui ne sont pas dépassées, et en même temps, on sait que cette dépendance fera son apparition dans les autres distribs d'ici 1 an ou 2.
Attendons que GTK+4 sorte et soit stable pour le considérer.
Tu vois, clairement, c'est aussi un conseil de quelqu'un qui n'est pas sur le terrain. :P
C'est vrai, mais c'est le cas de 99.99% des logiciels Libres. Je viens de regarder (encore) l'activité de Blender. Ils ont à peine plus de gros développeurs que nous (si je regarde 2018, je dirais 4 vraiment gros développeurs). Ensuite oui, je suis sûr que Firefox ou Apache n'ont pas ce problème. Mais pour en arriver là, ce n'est pas juste un ou 2 commerciaux qu'il faut engager.
Et je suis totalement d'accord, puisque j'ai répondu que c'est exactement ce que l'on fait! ;-)
Il y a un million de trucs à répondre à ça! Déjà, comment le paie-t-on? On est une asso, on fait du tout-libre, etc. Donc effectivement si quelqu'un veut aider bénévolement parce qu'il veut promouvoir le la création Libre (un des objectifs de l'asso), on n'est pas contre. Dans les faits, on a eu des aides ponctuelles déjà, de par le passé, mais on ne va pas pousser ces gens à travailler d'arrache-pied sans être payés. Perso j'aimerais que tous ceux qui travaillent soient payés (correctement en plus), idéalement. Je fais partie de ces gens qui considèrent que c'est normal de payer quelqu'un pour un travail et je ne veux surtout pas trop profiter des gens (même raison pour laquelle je n'aime pas les stages par exemples, et surtout les stages non-payés; on nous en a encore proposé y a pas longtemps et c'est pour moi de l'exploitation de jeune mains d'œuvre). Or si on paye cette personne, ben nous on n'a plus de sous (je rappelle que depuis quelques années, on jongle avec quasi rien).
Ensuite y a la fameuse réponse, oui mais cette personne est censée ramener plus que ce qu'elle coûte! Donc une fois engagée, elle ramènera de quoi vous payer. Déjà ce n'est pas sûr. De même que j'expliquais qu'il peut y avoir de mauvais dévs, il peut aussi y avoir de mauvais commerciaux (quand on parle de financement, ou marketing pour la pub; au passage, tu me parles de 2 postes différents là comme si c'était la même chose!). Donc ce n'est pas sûr qu'ils ramènent quoi que ce soit. Peut-être se retrouvera-t-on à les payer pendant 6 mois sans qu'il n'y ait aucun retour puis on doit leur dire au revoir, et entretemps, le projet a pu tomber à l'eau (car un développeur et une réalisatrice, ça mange aussi). Ensuite y a le fameux sujet: ces gens sont-ils vraiment ceux qui ramènent l'argent? On retrouve souvent ce sujet de discussion lorsqu'on se demande s'il est vraiment normal de payer des CEOs des prix exorbitants (et l'une des 2 réponses est souvent: oui mais ils sont censés ramener plus que leur salaire). Soyons honnête 2 minutes, les commerciaux sont ceux qui mettent leur nom sur le papier et qui signent, mais en général, sans le travail des techniciens (développeurs, animateurs, etc.) qu'ils ont vendus, y aurait rien eu à vendre. Prenons l'exemple de cette récente donation de 400 000 $ à GNOME/GIMP. Cela a-t-il été ramené par les commerciaux/CEO en arrière-plan qui ont démarché le donateur? Peut-être (ou pas, j'en sais rien, c'est pas écrit). Ce donateur aurait-il donné de toutes façons si y avait juste eu des développeurs parce qu'il aime GNOME/GIMP indépendamment d'un quelconque démarchage? Peut-être aussi. Le fait est qu'on n'en sait rien pour GNOME. Ce n'est malheureusement pas si simple à répondre, mais il est vraiment très pertinent de se poser la question.
Par contre côté GIMP, on peut répondre tout de suite: on ne savait rien de cette affaire, on n'a pas démarché, donc cette donation n'a rien à faire avec un quelconque marketing/commercial (et non ce n'est pas GNOME qui a demandé pour nous). Ce qui tend à invalider l'assertion qu'il faille du marketing pour de gros financements. :-P
Très bon exemple, si je me souviens bien, à l'époque (qui a duré de nombreuses années, alors même que Wikipédia était déjà connue et dans le Top 10 mondial des sites visités), leur seul employé était un admin. Car au final, ça sert à rien d'avoir du marketing et du commercial si l'exécutif ne fonctionne pas. La première chose à faire, c'était d'avoir un site qui fonctionne. De même que pour nous, la première chose, c'est de faire un film. :-)
Alors oui, je suis entièrement d'accord avec tout ce que tu dis sur le fond. Je ne me méprenais pas sur ton commentaire précédent non plus, de même que je veux être clair pour que tu ne te méprennes pas sur le mien. Mes réponses ne sont pas aigries ni en colère, ni quoi que ce soit de négatif. C'est pour cela que j'essaie de les parsemer de smileys (mais apparemment ça marche pas). Et là, quand je te réponds, je souris. Promis, c'est pas un mensonge! :P
Je sais aussi que mes longs commentaires à rallonge (j'arrive pas à faire court!) peuvent faire croire le contraire, mais ils ne signifient pas un état de désaccord.
Donc, reprenons: oui je suis d'accord… mais comme je l'ai expliqué, ce n'est pas si simple. Dire "il vous faut du marketing", c'est une recette de grand mère qui est à la fois évidente et à la fois pas en phase avec le monde réel qui ne prend pas en compte le fait qu'il faut payer cette personne, que ce n'est pas dit que cette personne va vraiment ramener des fonds, et surtout que ce n'est absolument pas sûr que je n'aurais plus à me soucier de rien. Par exemple, je l'ai dit, par le passé, on m'a déjà proposé de m'aider pour du financement (qu'on n'a pas eu), et au final, j'ai passé 90% du temps sur le dossier car c'est moi qui connaissais le mieux le dossier (note que je n'en veux pas du tout à cette personne qui m'a quand même aidé sur les 10% et je suis reconnaissant, mais c'est pas ce que j'appelle "ne plus se soucier des problèmes"). Ça c'est la réalité. :-)
Merci beaucoup pour cela! :-)
Perso je relativise notre taille. Oui on est petit et ridicule, et c'est pour cela qu'on ne peut pas engager quelqu'un en espérant qu'il soit doué et ramène soudainement beaucoup, tout en se mettant à négliger tout l'exécutif. En même temps, on arrive à tenir depuis quelques années. J'y crois personnellement. Certes cela ne m'empêche pas de régulièrement rappeler les gens de notre existence en demandant de nous soutenir, mais je suis confiant que ça va aller en s'améliorant, même si j'ai aussi mes périodes (très régulières) de doute.
En fait je pense que tes conseils sont vrais, mais simplement mettent la charrue avant les bœufs. Ils ne seront applicables que quand l'asso aura réussi à nous rémunérer convenablement d'abord. Un projet qui ne pense pas à l'exécutif d'abord ne vaut rien. Et ce jour là, quand on aura des sous en plus, alors on pourra penser à engager du marketing.
Wikipédia, c'était pareil, ils ont commencé par rémunérer l'exécutif. De même que la fondation Blender, quand ils ont eu des sous, ils ont payé du développement (et des animateurs avec leurs fameux Open Projects), etc. On ne commence pas un projet sans sous avec du marketing et du commercial. Enfin si, certains le font. On appelle ces projets des vaporwares. :P
En tous les cas, c'est mon point de vue et aussi la position de LILA à ce jour. Peut-être qu'on a tort (mais je crois pas).
Ah et dernier détail: tu ne peux pas nous comparer avec la Blender Foundation (née en 2002), la Wikimedia Foundation (2003), la Mozilla Foundation (2003), la Linux Foundation (2000) ou je-ne-sais quelle autre fondation ou association qui ont 15 ans ou plus, qui fonctionne confortablement et avec laquelle tu nous compares (nécessairement car tu cherches des points de comparaison et ce sont les organismes que l'on connaît bien dans le Libre). LILA existe techniquement depuis presque autant (on l'a fondé avec un ami en 2005, pour un projet de Musique Libre qui n'a pas connu le jour), mais dans les faits, elle est tombée en sommeil et est née à nouveau en 2015. Si tu veux nous comparer, prend les autres organismes nés récemment et tu verras qu'elles sont toutes aussi petites que nous, voire qu'elles ont plus de mal que nous.
Il y a 15 ans, déjà c'était plus simple car il y avait encore peu de projets, donc dès que l'un d'eux émergeait avec du code fonctionnel et commençait à se professionnaliser, les gens se ruaient dessus avec leur portefeuille ouvert. De nos jours, les projets florissent quotidiennement. Les gens donnent toujours, mais ils répartissent leurs dons. Regarde donc tous ces autres projets récents dans le Libre: ils ont tous autant de mal que nous.
En outre, même ces gros projets d'antan n'ont pas commencé avec les sommes de maintenant. Donc il faudrait nous comparer avec leur situation d'antan (probablement un peu meilleure que nous, car peu de projets à l'époque encore une fois, mais meilleure de très peu).
Voilà. Je pense qu'on peut conclure ici. Encore une fois, mes longues réponses ne sont ni des attaques ni des défenses (je ne me suis pas senti attaqué). Ce sont juste des explications de notre situation, et je le fais en détaillant un peu comment marchent les choses de mon point de vue (qui peut être erroné, mais en même temps, c'est ainsi que je le vis au quotidien, donc même si j'ai peut-être tort, j'ai du mal à m'en défaire). Et donc oui, on professionnalise le développement de GIMP et la réalisation d'un film libre (ce sont des faits; on a du mal, mais on y arrive en partie); mais non, je ne pense pas que cela peut passer par l'emploi de gens au marketing à notre stade (sauf s'ils veulent le faire bénévolement pour LILA, mais même là, on ne peut pas accepter n'importe qui juste parce qu'ils veulent, et surtout je peux pas aller les chercher: ils doivent proposer d'eux-même, c'est une partie de la définition du bénévolat).
Désolé. Je suis conscient que c'est pas facile de voir l'état d'esprit des gens à l'écrit, surtout avec un long pavé comme les miens. :P
Merci. On pense aussi être sur la bonne voie, même si on est pas sûr que notre véhicule tiendra le coup jusqu'au bout parce que cette voie est un peu caillouteuse. Et oui on espère aussi qu'on trouvera du financement. ;-)
Si tu veux, et si tu es à Paris, je serais heureux d'en discuter autour d'un café (mon email traîne partout, notamment sur mes commits) et tu verras qu'il n'y avait pas méprise. Juste désaccord sur le process, mais sans aucun mauvais esprit. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP Fundation ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 10. Dernière modification le 04 août 2018 à 09:15.
Ben écoute d'un côté, on a une fondation (hypothétique) qui paieraient des salaires pour améliorer GIMP et de l'autre une association (non hypothétique, elle existe) qui paie des salaires pour améliorer GIMP. Mais le premier cas serait de la professionnalisation et le second une bande de potes hippies. Euh… Ce serait pas une nouvelle version du bon et du mauvais chasseur là? ;-)
Sérieusement c'est un peu triste. On a l'impression que vous vous attachez au nom. Parce qu'on n'a pas "GIMP" dans le nom, c'est soudainement pas "professionnel"? Ou alors je vois pas. Parce que soyons clair, c'est un peu la seule différence là.
Je pense que peu de logiciels peuvent se targuer d'avoir un développement aussi intense que nous. Attention, je dis pas qu'y en a pas qui ont un développement encore plus actif. Je suis sûr que Firefox par exemple nous coiffe au poteau. Par contre comparons par exemple avec un logiciel tel que Blender.
Voyons le nombre de commits dans GIMP (master) depuis le début de l'année et depuis début 2017:
Maintenant dans Blender (master):
Voilà, GIMP a plus de 40% de commits en plus sur les 8 derniers mois. Ensuite si on remonte le temps, Blender gagne du terrain, on a à peu le même nombre de commits sur les 20 derniers mois et ça s'inverse en remontant plus loin. Notre activité n'a fait que s'accélérer depuis des années, continuellement. Je sais pas trop ce que tu veux de plus.
Et tout cela, avec en gros 3 core développeurs (Mitch, Ell et moi-même) qui faisons à peu près le quart des commits chacun (puis y a d'autres développeurs, certains plus réguliers que d'autres). Je crois qu'on n'a vraiment pas de quoi avoir honte de notre petite équipe. Peu peuvent se targuer d'une telle activité.
Comme tu le soulignes toi-même, c'est juste une histoire de perception (ou encore "a priori"). Un logiciel comme Blender, on va lire qu'ils sont méga actifs, etc. Mais pas GIMP? Ensuite cette perception n'est heureusement pas généralisée, car (comme je le dis dans l'article), notre image a vraiment changée et je ne lis plus personne dire que le développement de GIMP est lent. Tu es le premier que je lis ressortir cela depuis un bon moment. :P
Ben les employés compétents et motivés aussi, je t'assure. Je ne sais pas exactement ton champs d'activité (mais si tu traînes ici, les probabilités que ce soit quelque chose dans l'informatique sont grandes!), mais dans le développement logiciel, tu trouves aussi (c'est à dire comme dans tout métier) beaucoup d'incompétents. L'argent ne fait rien à l'affaire.
Et pour avoir eu aussi mes expériences professionnelles dans le développement logiciel en entreprise (comme on peut s'y attendre), laisse moi te dire que notre petite équipe de bénévoles "hippie" n'a vraiment rien à envier à tes supers employés qui seraient plus à même que nous d'offrir aux gens ce dont ils rêvent. Franchement j'ai rarement vu un tel regroupement de gens compétents que dans notre micro équipe (non seulement les 3 au cœur, mais aussi ceux qui bossent sur GEGL, ainsi que certains réguliers qui font pas tant de patchs, mais quand ils en font ou quand ils réagissent, tu te dis que tu aimerais bien les voir plus souvent!).
En conclusion, je voudrais boucler et revenir à ce que j'ai dit au début de ce commentaire: oui LILA est professionnelle. Et lever des fonds participatifs pour employer des développeurs est exactement ce que nous essayons de faire. Franchement avant de parler d'engager de nouveaux développeurs/designers, on aimerait bien pouvoir avoir au moins assez pour payer ceux qui contribuent actuellement et aimeraient bien en vivre (nous sommes 2: le mainteneur de GEGL et moi-même sur GIMP, voire 3 en comptant Aryeom qui de temps en temps fait des illustrations pour gimp.org, des icônes, des ateliers, ou autres, et surtout aide en donnant continuellement des retours pour améliorer GIMP et son interface en tant que professionnelle l'utilisant au quotidien; aucun de nous n'a actuellement assez pour financer un salaire minimum).
Je dois avouer avoir un peu du mal à comprendre. Beaucoup nous disent que si nous faisions des crowdfunding pour améliorer GIMP, ils donneraient. Mais la réalité, c'est qu'on le fait depuis environ 2 ans maintenant (et oui, c'est officiel, nos crowdfundings sont listés dans la page donation de GIMP). On a donc déjà professionnalisé GIMP depuis 2 ans. Il ne tient maintenant qu'à vous tous de nous permettre de ne pas abandonner en si bon chemin (parce qu'on y pense plutôt régulièrement malheureusement). :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP Fundation ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 7.
Les fonds de GIMP ont toujours été gérés par la fondation GNOME. Cette annonce ne change absolument rien du tout. Mais vraiment rien.
Ensuite si on décide que cet argent peut aller en salaires, une partie peut éventuellement être donnée à LILA.
Encore une fois, relire mon commentaire. Je ne comprends pas pourquoi vous voulez absolument une "fondation" alors qu'on a déjà tout ce qu'il faut. C'est une obsession sur le nom?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bon
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Écoles d'ingénieurs: les frais augmentent. Évalué à 10. Dernière modification le 03 août 2018 à 09:13.
Cela implique que les étudiants doivent rentrer dans les cases. Si une personne décide de ne pas aller vers un boulot classique d'ingénieur centralien, et probablement avec un salaire moindre, alors il ne peut plus rembourser. Donc on le force à faire quelque chose de sa vie qu'il ne veut pas forcément.
Je ne dis pas cela au hasard. Il y a pas mal d'années par exemple, j'ai failli acheter un petit appart, pour lequel je me serais endetté pour des dizaines d'années et aurait été incapable de lâcher mon boulot d'ingénieur (sauf pour un autre, si possible avec le moins de vacances entre-deux). Puis je me suis ravisé et ai décidé que je préférais vivre bien. Par la suite, j'ai même démissionné (sans autre boulot en perspective), j'ai vagabondé, ai vécu dans plusieurs pays (en travaillant là-bas parfois, parfois non). Puis de nos jours, je fais du Logiciel Libre (pendant des années entièrement bénévolement) et je développe GIMP avec des salaires qui feraient rigoler (jaune) n'importe quel ingénieur (soyons clair, on parle même pas de salaire en sortie d'école, et de loin; mais vous êtes tous bienvenus pour aider à notre financement collaboratif si vous aimez GIMP ;p).
Mais globalement je suis heureux de ma vie, j'aime ce que je fais et mon but ultime n'est pas de rouler sur l'or (même si j'aimerais bien être bien payé, soyons clair; mais "vivre bien" passe en priorité).
Alors forcer les gens à prendre un prêt dès leurs premiers pas en tant qu'adulte signifie ne plus leur donner de choix sur ce qu'ils feront de leur vie. Ils doivent au plus vite marcher au pas. Ensuite certains, c'est exactement ce qu'ils veulent et ils sont très heureux avec cette vie. Mais pas tous.
Et la réponse éventuelle "ces personnes ne sont pas obligés d'aller en école d'ingénieur" n'est pas acceptable. Pourquoi serait-il interdit d'avoir de bonnes études d'ingénieur sans vouloir rentrer dans les cases professionnellement ni s'endetter? Tout ce que j'ai dit précédemment peut aussi s'appliquer à un ingénieur (comme à n'importe quel métier, donc n'importe quelles études).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP Fundation ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 10.
Il y a tout de même une différence de processus avec la Blender Foundation. Ils mettent le logiciel en avant, alors que sur ce projet, je préfère mettre la création en avant. Le logiciel libre est pour moi simplement une évidence (tout logiciel devrait être logiciel libre), pas un but. :-)
Et ça veut aussi dire que nous pourrions aussi contribuer à d'autres logiciels, pas seulement à GIMP (ce que d'ailleurs je fais, même si effectivement à ce jour, GIMP seul est environ probablement la moitié de mes contributions).
Il y a déjà plusieurs "problèmes" à un tel raisonnement. GIMP n'est à ce jour pas une entité du tout (pas une association, pas une entreprise, pas une fondation, rien d'enregistré). Nous avons un mainteneur, mais même là, cela reste une organisation extrêmement organique et qui arrive vraiment à s'auto-gérer (très bien en plus!) simplement par la bonne volonté et bienveillance des contributeurs principaux (franchement, c'est l'une des ententes les plus cools que j'ai connues dans le Libre, et c'est ça qui m'a fait rester). Si on doit citer un exemple typique de l'organisation "bazar" du Logiciel Libre, GIMP est probablement un des meilleurs exemples (voire l'un des seuls parmi les plus gros logiciels connus du Libre).
Or on aime tous cette ambiance, coordination et organisation bon-enfant, et sérieusement ça me ferait mal de pêter ça, en essayant d'y rajouter une structure plus rigide. Perso j'adore le fait que GIMP soit pas une entité définie, de même que j'aime aussi les organizations horizontales, les partenariats (genre SCOP en entreprises, un concept que j'aimerais bien faire un jour si je monte une boîte), bien plus que les hiérarchies.
Je pourrais essayer de le faire seul dans mon coin, par exemple en reformulant le but de notre association (LILA) pour en faire une GIMP Foundation, ou en créant une nouvelle entité, mais franchement cela pourrait être ressentie par les autres contributeurs (et probablement à raison) comme une sorte de coup d'état. Une prise de pouvoir par la création d'une entité dans notre coin qui utiliserait le nom GIMP alors que tous les autres sont cools avec l'organisation informelle actuelle. Franchement j'ai pas envie de ça. Je pense que la seule chose qui en ressortirait serait de ruiner le développement et les relations dans l'équipe GIMP. Et probablement cela ferait fuir les contributeurs (déjà qu'on n'est pas nombreux! Et notons que même si je me considère pas mauvais, je connais aussi mes limites; et je suis super heureux de coder aux côtés d'autres développeurs vraiment super doués; la dernière chose que je voudrais serait de les dégoûter de contribuer).
Aussi comme je le disais, nous on aime l'idée que notre but est de créer un film, des vidéos géniales pour Framasoft ou d'autres gens, même un jeu de société récemment pour une autre asso, etc. Le tout avec des logiciels libres que nous améliorons nous-même. Et non pas l'inverse: mettre l'accent sur un logiciel pour que d'autres utilisent. Donc je préfère LILA telle qu'elle est actuellement et n'ai pas vraiment envie qu'on en fasse une fondation GIMP.
Dernier point, soyons honnête un instant! Cette structure existe! C'est LILA! Bon je me contredis (exprès!), car je viens de dire juste à l'instant que nous ne sommes pas la fondation GIMP et ne souhaitons pas le devenir. Mais dans les faits, on développe GIMP et des projets autour. À ce jour, c'est plus ou moins 100% de ce que l'on fait. Si le besoin d'une telle structure, c'est d'avoir une entité officielle et enregistrée à laquelle donner, ou à laquelle se raccrocher de manière officielle, ben LILA fait parfaitement l'affaire et vous pouvez être sûr que votre argent est utilisée pour GIMP.
Maintenant cela peut changer. Peut-être que dans un an, 2 ou 10, on fera un projet en contribuant plutôt à Blender, ou Synfig, ou Inkscape (ou que sais-je encore). Et ce jour là, si ça ne convient plus, vous pourrez changer de crèmerie. Et surtout vous le verrez venir, et on l'annoncera en avance. Mais pour l'instant, on est ce qui se rapproche le plus d'une fondation GIMP. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Ghibli l'a aussi fait
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le libre intéresse un studio d'animation français. Évalué à 10. Dernière modification le 14 juillet 2018 à 10:56.
Je ne comprends pas pourquoi certains disent que Ghibli a libéré OpenToonz. Ce logiciel a été développé par son éditeur après un rachat d'entreprise. Cela n'a rien à voir avec une décision de Ghibli qui ne faisait qu'utiliser ce logiciel (fait qui a beaucoup été mis en avant pour promouvoir le logiciel certes), comme d'autres.
Quant à Cube, puisqu'ils font beaucoup de 3D, je sais que c'est surtout Blender qui les intéresse. J'ai un peu (rapidement) rencontré un des patrons dans leurs locaux y a quelques mois, et il a effectivement dit que Blender l'intéressait (sans que quiconque mette le sujet du libre ou de Blender en particulier sur la table, il en a parlé de lui-même en parlant des logiciels), principalement pour l'économie sur les licences. Il a aussi dit que ça prendrait probablement du temps pour y passer car les premières personnes à convaincre sont les réalisateurs (on rappelle qu'en animation, un réalisateur est un vrai technicien et il a aussi besoin de bien connaître les logiciels du pipeline) or ces derniers ont souvent leurs habitudes. Aussi il a dit qu'ils n'utiliseraient aucun des moteurs de rendu de Blender (pas même Cycles dont on parle beaucoup). Il a cité un autre moteur (dont je ne saurais plus dire le nom; probablement un moteur propriétaire d'ailleurs) en disant que les moteurs de Blender n'ont pas la qualité suffisante (d'après lui; perso, je ne saurais me prononcer).
Enfin perso, j'en ferais pas non plus une grosse news. Blender est déjà bien implanté dans le métier (même si clairement pas le n°1 non plus), on en entend régulièrement parler dans divers studios, voire certains l'utilisent effectivement déjà, Pôle Emploi finance des formations Blender, etc. En tous cas, c'est cool, mais rien de bien neuf. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Compiler
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNU Emacs 26.1. Évalué à 10.
Configurer avec le préfixe par défaut (
/usr/local), et surtout installer en root est le meilleur moyen de pêter un jour son système. C'est fortement déconseillé.De manière générale, il n'y a absolument aucune raison de faire quoi que ce soit avec les droits d'administrateur quand on compile un programme (bien sûr, hormis les quelques cas spéciaux de logiciels qui ont besoin de droits d'admin pour par exemple ajouter un setuid, ou logiciels très bas niveau, ou autre; je doute qu'emacs soit un de ces cas particuliers, sauf erreur), malgré les nombreux tutos qui pullulent sur le sujet et qui se recopient les uns les autres sans réfléchir.
En fait sous Linux, on peut (et on a toujours pu) installer des logiciels sans le moindre droit admin (encore une fois, sauf exceptions)!
Donc, déjà s'il y a une option générique des autotools à connaître, c'est
--prefixqui permet de choisir un préfixe d'installation perso. Dans mon cas, je prends souvent$HOME/.local. Ainsi l'appel devient:Puis au moment de l'installation, un simple:
Pas de
sudonécessaire! Vous avez tous les droits d'accès dans votre $HOME.Bien sûr, il est fort probable que votre système ne met pas les variables d'environnements appropriés pour trouver un logiciel dans
$HOME/.local(quoique j'ai déjà vu cela, ce préfixe est assez classique car il est parent de$XDG_DATA_HOME). Je conseille de rajouter cela dans votre~./.bashrc:Et voilà!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Typo
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le statut juridique des jeux video libres. Évalué à 5. Dernière modification le 06 juin 2018 à 18:04.
Ben non, comme le prouve BAud et tant d'autres. On peut vouloir repenser l'affirmation qu'on peut être propriétaire de la représentation/utilisation d'une œuvre parce qu'on en est l'auteur (droits d'auteur), ou de l'implémentation d'une invention (brevets) ou d'un nom ou logo (marque), etc. C'est un débat classique de société. Il n'y a donc rien d'absurde.
Par contre, non il ne s'agit pas de nier l'existence de ce concept. Le concept existe, c'est concret (par définition s'il y a un terme pour nommer le concept!), et surtout il est dans la loi française (donc non seulement il existe philosophiquement, le concept existe aussi légalement). C'est un fait. D'où ma réponse à BAud. Mais vouloir en discuter la légitimité est tout à fait approprié et n'a rien d'absurde.
Note que je ne dis pas que j'en discute entièrement la légitimité moi-même. Je suis plus intéressé par faire des choses concrètes en utilisant le système en place (à l'heure actuelle, c'est pas comme si j'avais le pouvoir pour changer la loi!), notamment en utilisant des licences libres, que juste discuter. Mais clairement ça se discute.
Euh… non pas du tout. Si tu veux vraiment faire ce genre de parallèle, à la limite c'est comme prétendre que Dieu n'existe pas (et encore! Je crois que tu mélanges des choux et des carottes pour aider ton propos avec un exemple assez absurde et surtout très trollifère. Tu arrives quand même à faire dériver une discussion sur la propriété intellectuelle vers le sujet beaucoup plus sensible de religion, c'est fort! :P). Personne ne dit que ces concepts/courants n'existent pas. Mais certains en discutent la légitimité, c'est tout.
Perso je ne comprends pas cette possibilité que tu évoques. La propriété intellectuelle existe légalement (en France du moins, je ne vais pas prétendre connaître les textes de loi de tous les pays, et si tu parlais d'un autre pays, on a juste commencé la discussion sur un quiproquo! :P). C'est un fait, c'est écrit noir sur blanc dans la loi, avec ces mots exacts ("propriété intellectuelle"). Y a rien à discuter ou à mettre ou subjonctif.
Ensuite interpréter la définition légale du concept, si c'est ce que tu voulais dire, oui c'est faisable.
Mais sinon à part discuter la légitimité du concept (avec éventuellement l'espoir de changer un jour la loi pour les gens contre ce concept), je vois pas trop ce qu'il y a d'autre à discuter.
Au final, j'ai bien assez discuté sur le sujet. La propriété intellectuelle est nommée dans la loi, c'est tout ce que je voulais dire dans mon commentaire. Néanmoins on ne peut pas nier que plein de gens en discutent la légitimité, genre constamment. Pour moi y a rien d'absurde dedans, et surtout y a pas de réponse évidente sur un sujet si complexe (à la fois philosophique et sociétal)… en tous cas pas une réponse qu'on trouvera sur Linuxfr sur un commentaire de quelques mots dans un fil de discussion quelconque. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Typo
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le statut juridique des jeux video libres. Évalué à 5.
Ta remarque était peut-être d'ordre philosophique. Dans ce cas là, j'ai rien dit!
Mais hormis les considérations philosophiques, selon la loi, la propriété intellectuelle existe bien malheureusement, puisque le code qui définit justement ce que sont le droit d'auteur, les marques, les brevets d'invention, etc. s'appelle le "Code de la propriété intellectuelle". :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Lignes de code
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Sortie de GIMP 2.10.2. Évalué à 10.
Ok, comme quoi, un commentaire, c'est plus clair quand on utilise des phrases complètes. ;-)
C'est vrai que ça fait beaucoup (même si j'ai pas pour habitude de regarder le nombre de lignes qui changent et que le nombre de lignes peut monter assez rapidement avec le code "boilerplate, etc.).
Je me souviens plus exactement comment j'ai fait ces stats y a quelques jours, mais en essayant d'en refaire maintenant avec git diff, je trouve:
Le premier commit est le premier commit du 28 avril 2018 pour le port GTK+3, le second étant le premier commit du 20 mai (jour de sortie de GIMP 2.10.2). La différence de compte doit venir que j'ai pris un autre commit de fin (comme j'ai préparé la news en avance bien sûr, un plus vieux commit), mais globalement les chiffres restent similaires (je voulais vérifier au cas où j'ai fait une faute en copiant!).
Comme tu as éveillé tout de même mon esprit critique, j'ai regardé en détail le diff. Et tu as raison, c'est trop! En fait y a une suppression d'un SVG compté par git comme 872001 lignes supprimées à lui-seul! Clairement ça plombe les stats et c'est pas du code. On tombe à 50.000 lignes supprimées pour 10.000 insérées. C'est sûr, c'est pas pareil! :-)
Bon on reste à une insertion pour 5 suppression, mais c'est moins qu'une pour 100.
Merci de faire remarquer. C'est tout de suite mieux quand tu fais des commentaires avec du texte dedans, tu vois! :P
D'ailleurs si les admins de linuxfr veulent corriger, c'est avec plaisir!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Limitations du flatpack
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Sortie de GIMP 2.10.2. Évalué à 6.
On peut pas résumer/lister ces limitations dans une bulle d'information.
Il faudrait que je fasse un journal pour en parler (c'est prévu), et éventuellement faire un lien depuis gimp.org.
Les sandbox, c'est aussi beaucoup une évolution des logiques de conception des logiciels.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Commit de fusion ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Sortie de GIMP 2.10.2. Évalué à 10.
C'est surtout le mainteneur qui déteste les commits de merge, et ceci dit, je suis assez d'accord dans le cas de GIMP.
En gros, le but principal d'un commit de merge, c'est essentiellement "garder l'historique". Un commit doit garder son hash à jamais pour pouvoir être toujours retrouvable, histoire de ne jamais casser des liens ou rendre des discussions sur un changement particulier incompréhensible (car tu ne peux plus retrouver le commit discuté si le hash a changé).
Ça a beaucoup de sens sur de très gros projets avec énormément de contributeurs, etc. et surtout avec des branches de longue haleine. Par exemple si la branche principale est celle du mainteneur et chaque "lieutenant" (ou sous/co-mainteneur) a des branches (voire un remote) à lui, etc. Dans un tel contexte, on veut faire en sorte que toutes ces branches publiques à vie indéterminée gardent leur historique pour garder toute la cohérence.
Dans un projet comme GIMP avec 3 ou 4 développeurs permanents (et pas mal de gens externes qui font juste un patch par ci par là), qui bossent directement sur la branche
master, ça a beaucoup moins d'importance. Quand on fait des branches de fonctionnalités, en général, on peut souvent juste les supprimer après coup, histoire de faire un peu le ménage. Une fois mergées, elles ne sont jamais retouchées. Et de toutes façons, même quand elles sont encore actives, nos branches ont en général quasi qu'un seul développeur (sauf à la toute fin, quand une revue est nécessaire et que quelques corrections sont faites éventuellement).Dans ce cas, le seul intérêt du commit de merge est quasi complètement annihilé. Par contre ses défauts sont toujours là, et assez énormes: les commits de merge rendent un historique de commits vraiment illisibles. Je sais pas si tu as vraiment vu des arbres de commits (en vue non-linéaire) de gros dépôts, et notamment lorsqu'ils ont mergés des branches qui contenaient des dizaines de commits sur plusieurs mois. C'est juste une source de mal de tête.
Et je parle même pas de la vue linéaire (celle par défaut d'un
git log) qui est rendue totalement inutile dans ce cas.Dans notre cas hypothétique d'un gros projet dont la branche principale est quasi jamais développée directement et ne sert qu'à merger des branches publiques (qui elles accueillent du développement), c'est encore gérable. Mais un projet avec du développement quotidien et des commits de merge, c'est vraiment assez horrible.
Personnellement je ne serais pas contre des commits de merge sur certaines fonctionnalités de longue haleine qui ont nécessité des semaines ou mois sur une branche à part. Mais le monstre créé par les github/gitlab qui te font des commits de merge de partout pour un rien (genre: un patch de typo? Hop commit de merge!), c'est une aberration et surtout un abus complet du système et de la logique de git.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]