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

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