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 à [email protected] 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
