Re: [fr-discuss] Rythme de sortie

Bonjour Denis,

Le 23.01.2015 12:24, Jean-Baptiste Faure a écrit :
> Bonjour Denis,
>
> Le 23/01/2015 11:45, Denis Radwan a écrit :
> > Bonjour,
> >
> > J'ai hésité un bon moment avant de poster vu que je ne vois pas 
> > comment
> > exposer mon point de vue sans prendre le risque d'être taxé de 
> > négativisme.
> > Je précise donc ici que mes propos se veulent constructifs et n'ont 
> > pas pour
> > but d'agresser quiconque.
> >
> > J'ai découvert hier dans ce post sur la liste « USER »
> > (http://nabble.documentfoundation.org/Writer-Ouverture-docx-tt4136894.html),
> > l'existence d'un bug ressemblant à un bug déjà identifié est considéré 
> > comme
> > résolu :
> > https://bugs.freedesktop.org/show_bug.cgi?id=81325
> >
> > Présent sur la 4.1, la 4.2 et la 4.3, … il est résolu pour la 4.4 et
> > suivante.
> > Ce bug me fait moyennement rire à 3 ou 4 jours du déploiement en 
> > direction
> > de 20 utilisateurs pour tests avant la migration prévue à partir de
> > mi-février.
> > Mais bon… il va falloir faire avec.
>
> ça ne fait rire personne en effet. L'information importante pour bien
> comprendre le statut de ce bug "résolu" est : WORKSFORME
> Cela signifie :
> - ceux qui ont essayé n'ont pas réussi à reproduire le bug sur les
> versions de développement 4.4. et 4.5 (master)
> - on ne sait pas ce qui a corrigé le bug sur ces versions. Dans le
> rapport de bug il n'y a aucun commentaire signalant qu'un correctif
> (commit) y a été apporté spécifiquement. C'est pour cela que ce bug
> n'est pas marqué RESOLVED FIXED parce qu'il n'est pas corrigé, juste ça
> marche.
> Cela explique pourquoi on ne peut pas backporter le correctif sur la
> branche 4.3 puisqu'il n'y en a pas.
>
> Je confirme que le fichier de test du commentaire #3
> (https://bugs.freedesktop.org/show_bug.cgi?id=81325#c3) est lu sans
> problème avec la 4.4.1.0+ (6 pages) mais mal avec la 4.3.7.0.0+ (1
> page), tout ça sur Ubuntu 14.10 64 bits.

En dehors des points mentionnés par Jean-Baptiste, tu soulèves une 
question qui a été abordée ici et ailleurs mais qui est très importante 
pour la compréhension du projet.
Le choix de sorties de version prévues à intervalles réguliers dans le 
temps (https://wiki.documentfoundation.org/ReleasePlan) est un modèle 
qui a été voulu dès avant le premier jour du projet LibreOffice. 
L'alternative est un modèle de sortie "quand c'est prêt", qui a été en 
place un temps (mais pas uniquement) au sein du projet OpenOffice.org . 
Ce modèle a généré énormément de problème, dont l'un des principaux est 
qu'il y aura toujours une bonne raison pour laquelle la version stable 
ne sera pas prête. C'est d'autant plus vrai qu'un logiciel comme 
LibreOffice est plus complexe que d'autres (Firefox par exemple, comme 
tu le disais).

Le modèle de sorties à date fixe nous apporte une certitude quant à la 
disponibilité d'une nouvelle version, et les deux branches permettent de 
se servir d'une branche plus testée que l'autre à n'importe quel moment 
dans le temps. Pourtant tes deux objections sont intéressantes:

- ralentir le rythme des sorties dans le temps: d'accord, mais à quelle 
fréquence? Le nombre de bugs diminuera-t'il? N'oublions pas que les bugs 
ne sont repérables que parce qu'on teste le logiciel, et que d'une 
manière assez constante, plus on ralentit le rythme de sortie de 
versions, moins il y a d'intérêt au développement par la communauté (de 
développeurs), et qu'il n'a pas été observé que la QA ait été vraiment 
plus efficace (même si pas mal de gens ont pu sentir qu'ils couraient 
après les sorties quand ils voulaient aider aux tests). Il n'y a pas de 
réponse facile, parce qu'il n'est pas dit qu'en ralentissant le rythme 
d'un mois on n'améliore pas la qualité au final, alors que si on la 
rallongeait de deux mois l'amélioration ne serait plus perçue à cause du 
désintérêt de développeurs et d'une moindre mobilisation de la QA.

- une version "ESR" ou "LTS". Oui, les entreprises utilisent souvent la 
ESR de Firefox, et du coup tu n'es pas le premier à suggérer quelque 
chose de similaire pour LibreOffice. La réponse est très simple pour le 
coup, car elle n'est pas technique - les LTS ou ESR ne sont pas des 
choses difficiles à faire techniquement. En revanche la réponse est 
commerciale ou économique: Canonical peut distribuer la LTS car elle est 
financée par ses clients; Firefox a une ESR parce qu'en dehors d'avoir 
500 millions en banque, ils ont aussi des contrats de support qui 
financent l'ESR. Dans le cas de LibreOffice, la fondation n'a pas ce 
genre de chose et il est assez improbable qu'elle pourrait fournir ce 
genre de prestations, donc une ESR (ou quelque chose qui s'en rapproche) 
est une option auprès des fournisseurs de prestations sur LibreOffice, 
spécialement ceux qui sont certifiés par la fondation.

Ceci étant dit, je ne sais pas ce qui est plus frustrant en termes de 
qualité que le situation dans laquelle tu te trouves; le bug non 
reproduit à deux jours du déploiement, ce n'est pas facile!

Charles.


--
Envoyez un mail à discuss+unsubscribe@fr.libreoffice.org pour savoir comment vous désinscrire
Les archives de la liste sont disponibles à http://listarchives.libreoffice.org/fr/discuss/
Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être 
supprimés