Prochaine mise à jour

[asw15]

J'ai lu vos différents échanges de ce weekend et pour tout projet comme dans la vie :

- Rien est simple
- Tout se complique
- Des hauts et des bas

Jean-jacques Sempé (dessinateur humoriste français)

[cherob]

Pour moi Darktable est un bel outil dont je bénéficie et que j'utilise très régulièrement depuis les toutes premières versions. C'est un outil qui a fortement évolué (par exemple au début, il n'y avait pas les masques !), et qui s'est enrichi en profondeur de façon très originale avec toutes la réflexion autour de la colorimétrie et de la théorie des ondelettes. C'est un outil qui nécessite pour moi un effort assez imortant de compréhension (et pour cela j'apprécie la doc et les tutos même en anglais), mais qui laisse aussi la place une approche plus visuelle et intuitive (finalement la photo retouchée me plait, et ça suffit).
Donc bravo à toute l'équipe de développeurs. De toute façon je ne suis pas informaticien et je ne pourrai pas faire pas le quart de la moitié du dixième de ce qui a été fait.


Ensuite j'ai découvert récemment et je comprends et suis les débats animés entre les développeurs avec en effets des éléments (arguments ?) factuels posés. Bon j'ai mon avis mais je l'ai déjà donné et je ne vais pas recommencer. Et puis manifestement, de débats animés on est est passé à une incompréhension puis à une animosité entre développeurs. C'est dommage pour les développeurs, pour Darktable et ses utilisateurs, mais c'est comme ça.

Alors, peut être que comme dans la chanson, sera-t-il bientôt temps pour Darktable d'écrire son testament:

" Trempe, trempe ta plume, Oh ! mon vieux tabellion,
Et de ta plus belle écriture,
Note ce qu'il faudrait qu'il advint de (mon corps) Darktable,
Lorsque (mon âme) ma table lumineuse et (lui) ma table noire ne seront plus d'accord,
Que sur un seul point : la rupture. "

Et puis, "pas de violence, c'est les vacances !".

[holly76]

Et puis manifestement, de débats animés on est est passé à une incompréhension puis à une animosité entre développeurs. C'est dommage pour les développeurs, pour Darktable et ses utilisateurs, mais c'est comme ça.

Pour ma part, je ne perçois pas d'animosité, ce terme me paraît excessif.
Je dirais plutôt un agacement certain.

Il me semble que le nécessaire recul à avoir pour faire des constats, et provoquer la prise de conscience de certains problème, n'est pas le même pour l'ensemble des développeurs.
Ça ne m'étonne guère, dans ma carrière j'ai connu des bourrins du code, des gars qui n'étaient préoccupés que de leur codage, heureux d'avoir réussi la prouesse de pondre un module en un minimum de lignes C, tellement minimaliste qu'il n'y avait aucun commentaire, et in fine absolument pas maintenable, même par eux-même après quelque temps. Bref, le problème des informaticiens, souvent individualistes, sans esprit d'équipe, difficiles à gérer. On peut comprendre que ça énerve ceux qui doivent travailler avec de tels individus.

[minimoose]

Cette discussion est étrange, à la fois inquiétante et rassurante pour l'avenir de Darktable.

J'ai 20 ans d'expérience dans mon métier. Je ne travaille pas dans l'informatique mais dans un domaine où je suis amené à utiliser de nombreux logiciels spécifiques. Et pour certains, j'ai assisté de loin ou de près à leur mise en place.
Absolument tous ont eu des difficultés similaires à celles exposées ici.

Et finalement, je vois toujours un schéma similaire dans la mise en place de ces logiciels:
1. une personne a une idée d'utiliser un logiciel pour faire telle tache métier. Il imagine souvent un truc simple de type une entrée, une sortie.
2. elle en parle à son chef qui trouve que c'est une bonne idée et lance le développement.
3. l'informatique commence à travailler et demande un cahier des charges décrivant ce que doit faire le logiciel. Là ça se complique car la personne qui a eu l'idée parle avec les termes de son métier comme si les informaticiens savaient exactement de quoi elle parle.
4. s'organisent alors des réunions réunissant plusieurs personnes du métier pour définir ce qu'ils veulent. Sauf que la plupart de ceux qui sont désignés, en fait, n'y sont sont pas intéressés.
5. tant bien que mal, le cahier des charges est fait par 2 des 10 personnes ayant assisté aux réunions, et la conception du logiciel avance.
6. une première version est fournie au métier pour la tester. Elle correspond techniquement à peu près au cahier des charges, sauf que l'interface n'est pas comme l'utilisateur l'avait imaginé, mais surtout l'utilisateur avait oublié de prendre en compte les cas particuliers dans le cahier des charges initial.
7. on révise le cahier des charges, toujours peu de gens du métier se sentent concernés.
8. Nouvelle version à tester, ça commence à être pas mal. Là les gens du métier qui s'en foutaient jusque là s'y intéressent, trouvent ça bien et commencent à avoir plein d'idées pour l'améliorer.... et la hiérarchie dit banco.
9. BADABOUM! les nouvelles fonctionnalités non prises en compte dès le départ s'intègrent mal, le budget et le calendrier restent les mêmes... Le logiciel finalement lancé irrite tout le monde, développeurs comme utilisateurs. Dans le meilleur des cas, le budget et le calendriers sont allongés mais ça n'empêchent pas les catastrophes industrielles (2 ans de retard, budget multiplié par 4, fonctionnalités de bases à peine fonctionnelles, certaines fonctionnalités critiques pour le métier qui ne fonctionnent pas... mais il faut y aller quand même, ça nous a couté trop d'argent).
10. dans certains cas, il faut des patchs et mises à jour pendant plusieurs années par la suite pour ne serait-ce qu'aboutir au cahier des charges.
11. dans le pire des cas, 3 ans après, on développe un nouveau bidule pour remplacer celui-là.

C'est un résumé mais c'est à peu près ça.

Là je donne l'exemple de la mise en place d'un nouveau logiciel, mais le même scénario existe pour des projets purement métiers. Il y a toujours des égos dans un projet pour profiter de l'opportunité de se faire mousser, quitte à desservir l'intérêt général. Et la hiérarchie est souvent aveugle à cela. Mettre en place des nouveaux process qui n'apportent pas de plus values voire ralentissent le travail, ça existe partout. Je me méfie toujours, par expérience, des gens qui parlent trop et qui sont trop enthousiastes. Et j'écoute particulièrement les gens discrets ou les râleurs constructifs.

Darktable ne semble pas très différent donc. Mais de ce que j'observe, Darktable fonctionne mieux (d'un point de vue utilisateur final) que certains logiciels métiers que j'utilise. Donc tout ne va pas si mal.

Néanmoins j'invite les développeurs à ne pas ignorer certaines alertes comme Aurélien Pierre peut en faire. Il me semble que la longévité d'un projet informatique nécessite une certaine "propreté du code". Ceci permet à la fois les développements au fil de l'eau et minimiser la puissance nécessaire à faire tourner le logiciel sur tout type de machine (pour DT, mon ancien portable avec un i5, 4 Go de Ram et une carte video correcte soufflait tout ce qu'il pouvait quand je bougeait les curseurs. Mon pc actuel avec un i7, 12 Go de Ram et une bonne carte vidéo a toujours un temps de latence avant d'afficher un résultat).

Enfin, pour calmer le débat et faire en sorte que tout le monde regarde dans la même direction, je ne vous conseillerais qu'une chose basique, que je répète sur tous les projets pro auxquels je participe: Revenez aux définitions et appelez un chat un chat.
Au fil du temps, on peut être amené à oublier ou mal interpréter les définitions des mots qu'on utilise, à tel point que 2 personnes pensant discuter d'une même chose en arrive en fait à parler de 2 choses différentes en utilisant le même mot.

- Si Darktable est par définition un logiciel tout en un, alors il est tout en un.
- Appeler un chat un chat, je ne sais pas si c'est le cas dans le projet DT, mais dans ma boîte, on aime bien donner 2 ou 3 noms différents à une même chose. C'est débile mais personne ne trouve rien à y redire (on a un logiciel qui a un nom métier, une url pour y accéder qui n'a absolument rien à voir avec le nom métier, et un autre nom quand on doit appeler l'assistance informatique). Je vous déconseille de nommer plusieurs fois une même chose ;-).

Je ne sais pas si ça aidera le développement de Darktable dans le futur, mais les similitudes me semblaient tellement évidentes avec d'autres de mes expériences qu'il me semblait utile de vous les partager.

[loicb]

Je lis régulièrement le forum, mais je n'interviens quasiment jamais. Cela fait un moment que je constate des tensions entre certains dev et comme je n'ai pas la chance d'avoir une bête de course (i3 4130 à 3.4Ghz et 12 Go de RAM), je ne peux que constater que dartable rame beaucoup pour mes développements et qu'il y a des modules que je ne peux pas du tout utiliser.

Je ne veux pas rentrer dans la polémique de savoir que de Aurélien, Pascal et autres à raison ou tort. Je pense qu'il y a du bon et du moins bon chez tout le monde. Je regrette simplement qu'il ne puisse pas y avoir d'entente.
Aurélien a développé de très bons modules, même si j'ai toujours du mal (et c'est un euphémisme) avec filmique sur certaines photos, mais ce n'est pas le sujet (même en appliquant ce que recommande Aurélien).

Je pense qu'il serait bien d'avoir une feuille de route commune entre les devs avec quelques points. Je précise tout de suite que je suis seulement prof des écoles et pas compétent en programmation :
- alléger le logiciel en enlevant des modules qui ne servent plus du tout. Le problème majeur est qu'en ouvrant une image traitée avec d'anciens modules, on va avoir des "merdes" puisque certains modules utilisés n'existent plus. Franchement, combien de personnes refont un développement des mois voire des années après le premier traitement ? En allégeant les modules, on allégerait forcément dt. Et au pire, on utilise un module plus "modernes" pour refaire notre traitement.
- améliorer le code puisque d'après ce que je comprends, il y a depuis un moment des modules et des fonctionnalités bugués et la solution est de mettre des pansements ou des attelles plutôt de que tout refaire. Ça alourdit donc le logiciel.
- développer éventuellement de nouvelles fonctionnalités, mais en ayant comme objectif premier que ces fonctionnalités ne soient pas basées sur des rustines.

Je pense que ce qui manque un peu au projet (mais ce n'est pas tout), ce sont des personnes qui ne sont pas des devs. En effet, les devs peuvent avoir des visions "codes", alors que des utilisateurs lambda vont plutôt raisonner en "fonctionnalités", "simplicité d'utilisation"...

À mon niveau, je ne sais pas comment je pourrais aider le projet vu que je ne n'ai pas de compétence dans le codage. J'ai participé pendant plusieurs années au projet OpenOffice.org (depuis la version 1.1.1 de mémoire) en faisant des traductions, recherches de bugs... et les problèmes actuels me font un peu penser à ce projet et au fork : les devs principaux ont forké vers LibreOffice et on sait toujours aujourd'hui que LO fonctionne bien alors que OOo est quasiment mort.

Pour finir, je tiens à remercier grandement tous les devs et les personnes qui participent au "projet" darktable.

[Manu38]

Allez, je remet un jeton dans la machine ;-)

Aurélien a publié un article expliquant plus en détail le pourquoi de son fork : https://ansel.photos/fr/news/darktable-d...u-ralenti/
Au delà de son ton habituel très engagé (voir polémique), il donne des exemples clairs par lesquels chacun pourra se faire son idée sur l'utilité ou non d'un fork.
Notamment, les extraits de code sont intéressants pour qui sait les lire.

Avant de me faire taper dessus je tiens à préciser que je reste un fidèle (et heureux!) utilisateur de darktable, je cherche pas à choisir un camp mais juste à suivre la vie de mon logiciel préféré.

[pascal]

@Manu38 : J'ai demandé la suppression de cet article qui insulte purement et simplement l'équipe de dev. Et une bonne partie des remarques sont fallacieuses car Aurélien n'est tout simplement pas devs et ne comprend pas la complexité de l'architecture. Donc merci d'éviter de partager des articles qui ne propagent que la haine.

[Manu38]

Pour le coup je ne suis pas d'accord avec vous, certes le ton d'Aurélien est très polémique, je l'ai dit. Certains se trouveront peut être insultés par ses propos, je le conçois.

Mais justement il a fait l'effort au delà des mots de pointer un certain nombre d'exemples qui justifient son choix. Là c'est factuel.
Après il s'agit peut être de points anecdotiques qui ont été montés en épingle mais le fait est qu'ils existent ou ont existé.

[pascal]

> Pour le coup je ne suis pas d'accord avec vous, certes le ton d'Aurélien est très polémique

Lit l'article stp, et tu verras qu'il y a clairement des insultes envers les devs actuels. C'est inacceptable.

[Manu38]

D'accord avec vous sur la forme.
J'ai mis ça de côté car je commence à avoir l'habitude du style d'Aurélien.
Je me suis focalisé sur le fond, c'est ça qui me semblait intéressant.

Bref désolé d'avoir remué le couteau dans la plaie. J'aime juste avoir l'avis des uns et des autres. ;-)