Re: [fr-qa] Re: Méthode de développement de Libre Office

Le 23/02/2017 à 11:38, Olivier R. a écrit :
> Bonjour,
>
>
> Scrat wrote
> > mais ne pourrait-on pas introduire dans le développement de Libre Office
> > une véritable démarche qualité?
> Je ne code pas sur LO puisque je ne connais pas le C++, mais je suis
> régulièrement le développement de LO en regardant régulièrement la liste des
> patchs introduits sur le code.
> Il est faux de dire qu’il n’y a pas de démarche qualité. La suite est
> beaucoup testée… Des tests, les dévs en ajoutent constamment.
> http://linuxfr.org/news/sortie-de-libreoffice-5-3#qualit%C3%A9-de-code
>
>
>
> Scrat wrote
> > j'ai du mal à comprendre ces "effets de bords" systématiques qui
> > bousillent des parties du code qu'on croyait (à tort) blindées chaque fois
> > qu'on introduit de nouvelles fonctionnalités.
> Oui, mais justement, ajouter des tests n’empêchent aucunement les
> régressions. Ça empêche uniquement les régressions sur ce que vous testez,
> mais ce n’est qu’une partie de ce qui est possible, quoi qu’on fasse. C’est
> utile pour éviter des régressions mais pas les régressions.
>
> Sur Grammalecte, j’ai plus de 6000 tests. J’en ajoute régulièrement. Ai-je
> moins de régressions pour autant? Je n’en ai pas vraiment l’impression.
> Certes, les bugs d’autrefois sont sécurisés pour éviter le retour des faux
> positifs testés, pour garantir que certains fonctionnements… mais ça
> n’empêche aucunement l’apparition de nouvelles régressions, de nouveaux
> problèmes. Dès que j’ajoute une règle ou en modifie une autre, malgré tous
> les tests, je sais que je vais avoir des effets de bord quelque part. Il y a
> toujours une chose à laquelle je n’ai pas pensé, malgré mes efforts pour
> envisager tous les cas de figure.
>
>
>
> Scrat wrote
> > N'est-il pas possible de programmer de façon plus "étanche", de sorte que
> > chaque fonctionnalité ne puisse pas être affectée par toute modification
> > d'une autre partie du code ?
> Les effets de bord, c’est précisément ce qui est difficile à éviter avec le
> C++, le langage s’y prête bien. Ce n’est pas pour rien que Mozilla a créé le
> langage Rust, qui offre des mécanismes de sûreté.
> https://www.quora.com/How-does-Rust-enforce-safety
>
>
>
> > Vous prétendez vouloir sortir la meilleure suite bureautique, mais
> > franchement, vous vous tirez dans le pied à chaque nouvelle version.
> > Comment voulez-vous qu'un responsable de parc informatique déploie ce
> > logiciel en entreprise s'il n'est pas assuré de la pérennité des
> > fonctionnalités existantes ?
> À mon avis, le problème n’est pas tant le développement que le marketing
> fait autour de ces versions… Seules les dernières versions .6 ou .7
> devraient être marquées stables… Si vous vous contentiez de ces versions,
> auriez-vous autant à vous plaindre? Mais aurions-nous autant de testeurs si
> on attendait autant pour déclarer stables ces versions?
>
>
> Par ailleurs, réflexion faite, je pense aussi que TDF devrait engager
> quelques dévs pour se focaliser sur les bugs les plus irritants pour la
> communauté, établis par un processus de vote ou par un comité d’utilisateurs
> quelconque. Les pauvres devront se contenter de faire de la correction de
> bugs, mais je crois aussi que ça apaiserait les esprits. :)
> Parce qu’il est vrai qu’on a le sentiment parfois que certains problèmes
> sont injustement considérés comme non prioritaires. Comme celui des
> lettrines. Préservez les documents, ça devrait être prioritaire.
Peut être que le risque serait alors que les développeurs laissent alors 
le "sale boulot" à TDF et ne se sentent plus impliqués dans les bugs 
qu'ils créent

Un compromis, serait de faire une liste des bugs hérités d'OpenOffice et 
bien embêtants et de faire un appel d'offre pour leur correction.
Une démarche ponctuelle, qui pourrait être renouvelée.

Sur le même principe, on peut cibler des domaines, comme la qualité de 
rendu des documents, la gestion des styles, la gestion des images

La question reste la même. y-a-t-il un problème de qualité de la suite 
(quelque soit les efforts faits par les devs et TDF pour y remédier.)
Si on considère que oui, alors on cherche des solutions, et il n'y a pas 
de tabou. Si considère que non, alors on laisse filer. Mais il faut 
d'abord de prononcer, se mettre d'accord sur l’existence ou pas d'un  
problème

Et quelque part, l’existence de bug, ce n'est pas le fond de commerce 
des socités de support technique LO ?


Pierre


> Cordialement,
> Olivier
>
>
>
> --
> View this message in context: 
> http://nabble.documentfoundation.org/Methode-de-developpement-de-Libre-Office-tp4208151p4208750.html
> Sent from the QA mailing list archive at Nabble.com.


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