Re: [fr-discuss] Débat sur l'avenir de la suite

Le lundi 07 septembre 2020 à 18:58 +0200, Jean-Michel COSTE a écrit :
> Le 07/09/2020 à 18:17, Ocleyr2lalune a écrit :
> > j'ai l'impression qu'on arrive à une liste de demande de consommateurs
> >   Si ça va
> > trop vite, qu'on veut quelque chose de stabilisé, alors on s'attarde
> > sur la 6.4. C'est aussi un moyen pour laisser le temps qu'un certain
> > nombre de correctifs passent sur la 7.0.
> Le problème, c'est que des régressions apparues avec la 6.2 sont encore 
> présentes dans toutes les versions jusqu'à la 7.
> Oui, mais il me semblerait logique que pour une  régression, il me 
> semble logique que celui qui l'a introduite (en apportant une 
> amélioration ?) soit sollicité pour la corriger. Ce qui ne semble pas 
> être le cas.....
Je ne suis pas certaine que ça puisse être si simple. Déjà il faut
identifier le bout de code qui a provoqué la régression, et compte tenu
de la complexité du code (vu l'outil, ça me parait "normal" qu'il soit
complexe), la régression pourrait venir d'un truc en chaine. Et que ce
ne soit pas le bout de code de la nouvelle fonctionnalité qu'il faille
corriger, mais un autre. Tu peux avoir une régression parce que
l'implementation d'une nouvelle fonctionnalité, "révèle", utilise une
autre partie qui était imparfaite (mais n'avait pas été identifiée).
La version 7, elle n'est pas encore stabilisée. Il faudrait surtout
voir sir les bugs et régression en question sont actifs, s'il y a
beaucoup de personnes à avoir voté pour leur correction etc... A défaut
de ne pas savoir corriger un bug, le confirmer me parait quelque chose
de faisable quand on souhaite qu'il soit vraiment traité (c'est au
minimum de ce que j'essaie de faire, sur ce qui me parait bloquant au
moins).

> > je me rappelle de tes messages sur le passage de Firebird à HSQLDB pour
> > une version précédente.
> Ce n'est pas l'inverse ?
Peut-être... 

> > Se contenter de l'ooxml strict ne me choquerait pas
> Moi non plus !!
> > Avec mon petit bout de lorgnette, je me dis que contribuer à la doc en
> > ligne est peut être moins lourd que contribuer à la traduction des
> > guides.
> Désolé, mais un guide pas à pas pour réaliser quelque chose, c'est 
> certainement plus efficace que la "pêche aux infos". Vécu.
oui, peut-être aussi selon chacun. Je veux surtout dire par là que
l'exhaustivité ne sera jamais atteinte dans un guide. Il a pour but de
te donner les principes de fonctionnement globaux, pour chaque modules.
Une nouvelle fonctionnalité ajoutée, ne mérite pas forcément d'être
décrite dans un guide. Par contre, une nouvelle fonctionnalité, non
décrite, c'est gênant. Et quand je trouve une nouvelle fonction (celle
sur la personnalisation de la validité des données, les graphiques
croisés, la plage de couleur...), c'est dommage de ne pas avoir de
éléments pour les utiliser... (je n'ai pas vérifié ce qu'il en est pour
les GCD et la plage de couleur).
Là dessus, je me dis que l'effort de doc doit être collectif, et que si
un jour je documente la chose pour le boutlot, il faudra que j'en fasse
profiter la communauté. Et l'investissement est moins lourd qu'un
guide.

> Cordialement,
>
> -- 
> Jean-Michel COSTE

Bonne soirée

Claire

-- 
Envoyez un mail à discuss+unsubscribe@fr.libreoffice.org pour vous désinscrire
Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/discuss/
Privacy Policy: https://www.documentfoundation.org/privacy