Bonjour. [Mode râleur ON]
Je suis consterné par le nombre de régressions qui affectent systématiquement chaque nouvelle version de Libre Office. Exemples: - Après avoir fait la mise à jour de la branche 5.0 vers la branche 5.1, j'ai vu sur le forum Open Office, et constaté par moi-même, que les animations dans Impress ne fonctionnaient plus! Solution préconisée: passer à la branche 5.2. - Mise à jour vers la branche 5.2: les animations fonctionnent... mais on a perdu les lettrines ! - Mise à jour (prématurée, j'en conviens) vers la version 5.3.0.3 où je croyais à tort retrouver mes lettrines (mais ce sera en principe pour la 5.2.6 et la 5.3.1), et j'apprends sur cette liste QA que l'extension Grammalecte fait planter Libre Office, ce que j'ai pu constater par moi-même!!! J'avais abandonné Libre Office du temps de la calamiteuse (selon mes critères) branche 3.5 qui comportait beaucoup trop de régressions non corrigées après plusieurs mises à jour, puis j'y étais revenu à la sortie de la branche 4 qui corrigeait enfin mes régressions et qui m'avait paru plus stable. Je constate que la branche 5 renoue avec les détestables anciennes habitudes, à savoir introduire de nouvelles fonctionnalités à la façon d'un éléphant dans un magasin de porcelaine, c'est-à-dire en cassant tout ce qui marchait dans les versions précédentes !!! Je ne vais certainement pas me faire des amis avec ce post, mais ne pourrait-on pas introduire dans le développement de Libre Office une véritable démarche qualité? Parce que la démarche adoptée actuellement m'évoque plutôt celle du regretté Groucho Marx, le spécialiste ès catastrophes. Je ne veux pas dire par là que les développeurs sont des rigolos ni dénigrer leur travail considérable, car je me doute bien que la maîtrise du monstre qu'est le code de Libre Office n'est pas aisée. Mais bien que je ne maîtrise pas du tout le C++, j'ai tout de même quelques solides notions de programmations en Fortran et en Java, et 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. 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 ? Je sais bien que les compartiments étanches n'ont pas empêché le Titanic de couler, mais tout de même, il me semble qu'il faudrait revoir les méthodes de développement de Libre Office pour limiter ces "effets de bord". 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 ? Je comprends maintenant pourquoi les responsables du parc informatique de mon entreprise faisaient la sourde oreille à chaque demande de mise à jour de la part des utilisateurs. [Mode râleur OFF] Scrat, poil à gratter des développeurs. -- View this message in context: http://nabble.documentfoundation.org/Methode-de-developpement-de-Libre-Office-tp4208151.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