Re: [fr-qa] Re: [fr-users] Liste au père Noël !!

Bonjour Pierre,

Un peu rapidement parce que moi aussi, je vais réveilloner ;)
Le 30/12/2013 15:12, Pierre Choffardet a écrit :
[...]

> Ce n’est pas vraiment ce que je voulais dire. Ce genre de problème est
> inévitable effectivement.
>
> Donc, comment faire pour que cela arrive le moins souvent possible, et
> que faire si cela arrive.
>
> Comment faire pour que cela arrive le moins souvent possible ? (outre ce
> qui est déjà fait)
>
> Il me semble que la durée de vie d’une version est trop courte, en
> particulier, il y a un temps trop court entre chacune des versions en
> fin de vie.

Comme je te l'ai dit, TDF n'a pas les moyens de prendre en charge des
versions de vie plus longue, les entreprises autour de TDF le propose
via un support payant.
> La régression introduite entre la 4.0.5 et la 4.0.6 a été détectée, mais
> il n’y avait pas le temps de la corriger. C’est pourquoi je pense qu’il
> faut allonger la durée entre la RC1 et la RC2 (un ou deux mois
> carrément. ceux qui veulent des versions bien stables peuvent attendre)
> de la dernière version d’une branche.

ou faire corriger les bugs par leur support.
> Maintenant, c’est arrivé.
>
> Actuellement, les versions proposées de Lo en téléchargement posent
> toutes deux des problèmes de plantages lors de l’utilisation des
> tableaux avec Impress.
>
> Je ne crois pas que l’on soit là dans l’utilisation d’une fonction
> obscure de LO. Ce genre de chose me parait inadmissible. il faut donc
> soit revenir à la version 4.0.5 en téléchargement soit corriger
> rapidement ce problème et proposer une version 4.0.7 qui corrige ce bug
> (et dans la foulée celui du méli-mélo des styles d’impress)

La 4.0.x est en fin de vie et ne sera bientôt plus supportée, en ce qui
concerne les bugs de localisation, pour ma part, je ne les corrige plus,
je n'ai pas les moyens de maintenir trois versions non plus.
> Mon sentiment est que la politique de LO est tout autre. Ce bug ne sera
> pas corrigé, en particulier parce qu’il ne semble pas se manifester sous
> la 4.2.0. on va donc rapidement faire disparaitre la branche 4.0.x et
> forcer les utilisateurs à utiliser la branche 4.2.x qui devront donc
> supporter les bugs de cette jeune version.

Avant, il y a la 4.1.x. Nous mettons en place une méthode qui permet de
trouver le commit qui a pu provoquer une régression, nous appelons cette
méthode bibisect, pour l'instant sous Linux, elle devrait bientôt être
fonctionnelle sous Mac et une interface est en cours de développement
sous Windows. Cela permettra d'aller directement à la cause de la
régression et donc de les corriger plus vite. Une explication ici:
https://wiki.documentfoundation.org/QA/HowToBibisect
Mais cela veut dire aussi qu'on les repère rapidement entre deux alpha
ou beta.
> On avance à marche forcée vers les nouvelles fonctionnalités qui sont
> donc de plus en plus nombreuses à devoir être maintenues, en même temps
> que les travaux en profondeurs sur le code (nécessaires bien sûr) font
> apparaitre de nouvelles régressions. il s’en suit une dégradation rapide
> de la qualité de la suite

Pas seulement les nouvelles fonctionnalités, des bugs anciens sont
corrigés dans les nouvelles versions. L'essentiel des nouvelles
fonctionnalités vient du GSOC, il faudrait aussi tester ces
développements bien plus que les autres.
> Je voulais ajouter qu’il est bien dommage qu’on ne puisse pas
> télécharger une version de LO corrigeant le méli-mélo des styles, car je
> ne sais pas si c’est la source des bugs que j’ai présenté sur la liste
> QA-fr et donc si je dois faire un rapport de bug

Je n'ai pas le temps de tester en ce moment et la RC2 arrive le 06/01
normalement, donc c'est dans peu de temps.

À bientôt
Sophie


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