16-01-19, 01:46
Bonjour à tous. Petit nouveau, mais ayant suivi toutes les dernières vidéos d'Aurelien où il a pesté abondamment sur le pipeline de darktable (et à juste titre autant que je puisse en juger), j'avais tout de même quelques remarques (qui sont peut-être inutiles vu que les choses ont l'air d'avancer dans une direction plus supportable).
La première est : dans un contexte de production professionnel de photos, à quelle fréquence on retournera à des vieilles photos déjà traitées ? Si la réponse est "rarement", la question de la rétrocompatibilité est à mon avis superflue tant que l'on peut avoir deux versions de darktable en parallèle. Je suppose qu'un photographe dont c'est le boulot créé suffisamment de matériel pour travailler surtout sur ses dernières œuvres, mais peut-être me trompe-je.
La seconde : dans le cas d'un fork vers un "nouveau darktable" (que j'appellerai -ng), il devrait être possible d'ajouter la version de darktable dans les fichiers XMP et afficher un avertissement "Vous travaillez sur un développement effectué avec une version antérieure de darktable, le rendu risque d'être différent" si l'on ouvre avec darktable-ng, avec un bouton "OK j'update le XMP et j'éditerai ce fichier avec darktable-ng dans le futur". L'utilisateur ferait ainsi le choix volontaire de profiter des nouvelles fonctionnalités de -ng, en toute connaissance de cause.
Enfin, l'exemple de Python est comme cela a déjà été mentionné à double tranchant. Toutefois, il est indéniable que 1) les débutants ne font plus de Python2 ; 2) les développeurs Python, même chevronnés, goûtant aux fonctionnalités spécifiques de Python3 retournent rarement en arrière, particulièrement pour les dernières versions ! 3) il reste tout à fait possible d'avoir les deux en parallèles (même si c'est particulièrement c****t de passer tout le temps de l'un à l'autre). Enfin, sans insulter la communauté darktable, je pense que son impact est tout de même moindre que celui de Python dans le paysage informatique mondial
.
De mon point de vue (naïf), je pencherai plus pour un changement de version majeur (darktable3?) afin que la communauté de traducteurs/porteurs/testeurs ne partent pas en courant ; si possible après une négociation avec les développeurs historiques. Dans tous les cas, merci à tous les devs actifs !
La première est : dans un contexte de production professionnel de photos, à quelle fréquence on retournera à des vieilles photos déjà traitées ? Si la réponse est "rarement", la question de la rétrocompatibilité est à mon avis superflue tant que l'on peut avoir deux versions de darktable en parallèle. Je suppose qu'un photographe dont c'est le boulot créé suffisamment de matériel pour travailler surtout sur ses dernières œuvres, mais peut-être me trompe-je.
La seconde : dans le cas d'un fork vers un "nouveau darktable" (que j'appellerai -ng), il devrait être possible d'ajouter la version de darktable dans les fichiers XMP et afficher un avertissement "Vous travaillez sur un développement effectué avec une version antérieure de darktable, le rendu risque d'être différent" si l'on ouvre avec darktable-ng, avec un bouton "OK j'update le XMP et j'éditerai ce fichier avec darktable-ng dans le futur". L'utilisateur ferait ainsi le choix volontaire de profiter des nouvelles fonctionnalités de -ng, en toute connaissance de cause.
Enfin, l'exemple de Python est comme cela a déjà été mentionné à double tranchant. Toutefois, il est indéniable que 1) les débutants ne font plus de Python2 ; 2) les développeurs Python, même chevronnés, goûtant aux fonctionnalités spécifiques de Python3 retournent rarement en arrière, particulièrement pour les dernières versions ! 3) il reste tout à fait possible d'avoir les deux en parallèles (même si c'est particulièrement c****t de passer tout le temps de l'un à l'autre). Enfin, sans insulter la communauté darktable, je pense que son impact est tout de même moindre que celui de Python dans le paysage informatique mondial
.De mon point de vue (naïf), je pencherai plus pour un changement de version majeur (darktable3?) afin que la communauté de traducteurs/porteurs/testeurs ne partent pas en courant ; si possible après une négociation avec les développeurs historiques. Dans tous les cas, merci à tous les devs actifs !