Je suis d'accord avec le nom "packager" (empaqueteur ?) plutôt que "maintainer" ici (être mainteneur c'est un rôle upstream), même si les distributions au niveau local parlent de mainteneur pour "mainteneur du paquet".
Je suis encore plus d'accord avec le fait que c'est un bon journal : une tranche de vie bien racontée.
L'auteur aurait peut-être pu mieux montrer que la situation est toujours un peu plus nuancée que ça. Les développeurs de Pale Moon sont peut-être des désagréables de naissance, mais il est raisonnable de supposer qu'ils ou elles n'ont pas commencé comme ça, et qu'il y a des explications à leur indélicatesse. Comme c'est une version de Firefox concentrée sur les performances, il y a sans doute des choix particuliers qui ont été fait sur les versions des bibliothèques externes ou sur les options de build, et une peur que quelqu'un empaquette incorrectement et que des utilisateurs trouvent ensuite le logiciel plus lent ou plus buggué qu'il ne l'est réellement—c'est peut-être déjà arrivé dans ces conditions-là. Ça n'excuse rien, mais ça permet peut-être de comprendre ce qui a mis les gens dans une situation aussi désagréable.
(Je pense que derrière on pourrait réfléchir plus globalement à cette manie de sortir des versions "remasterisées" de logiciels, pour "optimiser" tel ou tel aspect. Mon expérience est que souvent ces projets sont des pertes de temps, qui ne peuvent structurellement rien changer qui n'aurait été possible par un peu de contribution upstream (changer les options par défaut etc.), et qui manquent de la maîtrise technique pour offrir quelque chose de pérenne. Pas mal de temps perdu au final. Bien entendu, c'est souvent plus nuancé que ça, en particulier dans les domaines où la Q/A (Analyse de Qualité) est importante, parce que le comportement global du système est très sensible au fait d'avoir été bien intégré, bien configuré, etc. Ces spin-off "optimisées" jouent alors surtout le rôle d'une distribution clé-en-main, bien testée, pour un certain profil d'utilisateur sur lequel l'upstream ne se concentre pas. Ça a pas mal de sens pour les distributions multimédia par exemple (audio/vidéo, sensibilité aux latences, configuration de Jack, etc.), je suis un peu moins convaincu pour un navigateur web. Mais ce rôle (qui est en réalité un rôle de packaging, configuration et Q/A) permet aussi de comprendre l'état d'esprit des développeurs de Pale Moon et leur résistance à avoir de nouveau paquets downstream. Peut-être se voient-ils plutôt comme des fournisseurs d'un binaire Firefox bien testé pour les systèmes/distributions qu'ils utilisent eux-mêmes.)
[^] # Re: Mainteneur
Posté par gasche . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 10.
Je suis d'accord avec le nom "packager" (empaqueteur ?) plutôt que "maintainer" ici (être mainteneur c'est un rôle upstream), même si les distributions au niveau local parlent de mainteneur pour "mainteneur du paquet".
Je suis encore plus d'accord avec le fait que c'est un bon journal : une tranche de vie bien racontée.
L'auteur aurait peut-être pu mieux montrer que la situation est toujours un peu plus nuancée que ça. Les développeurs de Pale Moon sont peut-être des désagréables de naissance, mais il est raisonnable de supposer qu'ils ou elles n'ont pas commencé comme ça, et qu'il y a des explications à leur indélicatesse. Comme c'est une version de Firefox concentrée sur les performances, il y a sans doute des choix particuliers qui ont été fait sur les versions des bibliothèques externes ou sur les options de build, et une peur que quelqu'un empaquette incorrectement et que des utilisateurs trouvent ensuite le logiciel plus lent ou plus buggué qu'il ne l'est réellement—c'est peut-être déjà arrivé dans ces conditions-là. Ça n'excuse rien, mais ça permet peut-être de comprendre ce qui a mis les gens dans une situation aussi désagréable.
(Je pense que derrière on pourrait réfléchir plus globalement à cette manie de sortir des versions "remasterisées" de logiciels, pour "optimiser" tel ou tel aspect. Mon expérience est que souvent ces projets sont des pertes de temps, qui ne peuvent structurellement rien changer qui n'aurait été possible par un peu de contribution upstream (changer les options par défaut etc.), et qui manquent de la maîtrise technique pour offrir quelque chose de pérenne. Pas mal de temps perdu au final. Bien entendu, c'est souvent plus nuancé que ça, en particulier dans les domaines où la Q/A (Analyse de Qualité) est importante, parce que le comportement global du système est très sensible au fait d'avoir été bien intégré, bien configuré, etc. Ces spin-off "optimisées" jouent alors surtout le rôle d'une distribution clé-en-main, bien testée, pour un certain profil d'utilisateur sur lequel l'upstream ne se concentre pas. Ça a pas mal de sens pour les distributions multimédia par exemple (audio/vidéo, sensibilité aux latences, configuration de Jack, etc.), je suis un peu moins convaincu pour un navigateur web. Mais ce rôle (qui est en réalité un rôle de packaging, configuration et Q/A) permet aussi de comprendre l'état d'esprit des développeurs de Pale Moon et leur résistance à avoir de nouveau paquets downstream. Peut-être se voient-ils plutôt comme des fournisseurs d'un binaire Firefox bien testé pour les systèmes/distributions qu'ils utilisent eux-mêmes.)