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. 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+unsubscr...@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