[fr-discuss] Re: Rythme de sortie

Bonjour Charles,

> > > 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…
Sans vouloir t'offenser, ceci tient quand même un peu du faux dilemme.
Il existe d'autres solutions comme celle qui consiste, après constat d'un
éventuel problème récurrent,  à faire une pause pour réellement finaliser
une version fiable.
Dans la page du release plan, je lis :
« Note that the dates mentioned in the schedule might get shifted if there
are serious technical or other problems with the release. An extra RC might
be needed if the final release candidate does not fit the Release Criteria.
Such problem would shift the final release by one week or even more. »

Après l'épisode mouvementé du tri sous Calc, ce bug est un nouvel exemple de
ce que peut causer la nécessité absolue d'avoir à sortir une nouvelle
version dans des délais très courts.
D'autant plus que lorsque je télécharge le master via SIGUI, j'obtiens une
4.5… soit, trois versions en même temps et non 2.

Ce bug est reproductible sous la 4.3 par la simple copie du tableau de la
première page dans n'importe quel document sous Word 2013.
En affinant un peu, on se rend compte que l'insertion d'une « combobox »
dans un tableau dans Word, provoque le problème (voir un crash) à lecture du
docx sous Libreoffice.
Je n'ai pas MSOffice chez moi pour pousser plus loin les investigations.
Quoi qu’il en soit, Une version de Libreoffice à une durée de vie en tant
que version stable de l'ordre de 6 mois… Décider à 5 mois de la fin de vie
qu'il n'y a pas de nécessité de correction me gêne,… dans la démarche.

> > > > - ralentir le rythme des sorties dans le temps: d'accord, mais à quelle 
> > > > fréquence? Le nombre de bugs diminuera-t'il?…
J'en suis convaincu.

> > > > N'oublions pas que les bugs 
> > > > ne sont repérables que parce qu'on teste le logiciel,…
La QA à ses limites, et il est vrai que les testeurs sont noyés dans le
recommencement incessant des mêmes tests.
Car il ne s'agit pas de tester uniquement ce qui ne marchait pas. Il faut
tout reprendre à chaque fois.

Le test ultime de toute application est son utilisation en production, …
avec de vrais utilisateurs.
Est-il aberrant d'envisager qu'après avoir déclaré une version (vraiment)
stable (qui pourrait être la date de fin de vie actuelle) une période de … 3
mois par exemple, soit consacrée à la remontée des problèmes réels via les
forums par exemple… pour finalement donner lieu à une Version finale ?

> > > > il y aura toujours une bonne raison pour laquelle la version stable ne
sera pas prête...
C'est vrai. Mais il y a « pas prête » et « bugguée », ce n'est pas la même
chose.

L'absence d'une fonctionnalité sera toujours préférable à la présence d'une
dysfonctionnalité.

Je suis bien conscient de ne pas être en possession de toutes les
informations et d'avoir un point de vue d'amateur sur la question, ... mais
je m’inquiète un peu quand même pour l'image du produit.

Cordialement,

Denis




--
View this message in context: 
http://nabble.documentfoundation.org/Rythme-de-sortie-tp4137159p4137375.html
Sent from the Discuss mailing list archive at Nabble.com.

-- 
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