Liste au père Noël !!

24 décembre, super j'ai le droit de rêver et d'y croire ....
Sans volonté de troller ou quoi ou quesse voici ma petite liste au père
noël

Petite liste d'option pour visant le confort d'utilisation, rien de grave,
juste des petites améliorations pour un fainéant comme moi.

*Writer *
- Faciliter la commencement de la numérotation à la deuxième page d'un
document(sans passer par les styles).
- Bouton pour supprimer en 1 seul clic l’intégralité des styles et
formatages direct sur un texte, paragraphe page.

*Publipostage:*
- Bouton activer/désactiver la prévisualisation
- Activer le système de navigation des enregistrements en prévisualisation
- Activer l'actualisation des enregistrements (sans passer par F4 avec un
tableur comme base de données)

*Styliste:*
- classement des styles de paragraphes par catégorie dans le styliste (avec
le + le déploiement)

*Tableau:*
- faciliter (btn) la suppression/ajout de cellule avec adaptation largeur
tableau (à ce jour Alt + Suppr/Inser (3 secondes) + flèche)

merci de ne pas vous énerver sur le sujet ...j'ai juste pour le fun !!!
ajouter votre liste, non pas comme une revendication mais plutôt comme des
souhaits exprimés autour d'un vin chaud et devant une belle flambé qui
crépite
Ca aboutit, ça aboutit pas peut importe ! ça nous empêche pas de
travailler et de réaliser de beaux et vrais documents pro

Bonjour,

- Hiérarchie des styles de pages, au moins le format et les marges. Quand on ne change que le contenu de l'entête dans un nouveau style de page, il faut refaire un nouveau style à partir de zéro !

24 décembre, super j'ai le droit de rêver et d'y croire ....
Sans volonté de troller ou quoi ou quesse voici ma petite liste au père
noël

*Styliste:*
- classement des styles de paragraphes par catégorie dans le styliste (avec
le + le déploiement)

*Tableau:*
- faciliter (btn) la suppression/ajout de cellule avec adaptation largeur
tableau (à ce jour Alt + Suppr/Inser (3 secondes) + flèche)

Ceci était bien plus facile sous OpenOffice 1.0, fonctionnalité disparue sous OpenOffice 2.0 pour mieux paraître "comme Word".

Bonjour,

Bonjour,

- Hiérarchie des styles de pages, au moins le format et les marges.
Quand on ne change que le contenu de l'entête dans un nouveau style de
page, il faut refaire un nouveau style à partir de zéro !

Pour cette question précise, la solution : Styliste, cliquer sur le bouton de droite dans la barre d'outils ("Nouveau style à partir de la sélection").

Et ouala.

Ceci dit, d'accord avec toi sur la hiérarchisation des styles de page qui manque grandement.

Bonnes fêtes,

- Que dans Writer, on puisse faire sa barre d'outils avec les styles
utilisés, tous sans distinction de catégorie, et seulement ceux-là avec en plus la possibilité d'ajouter un bouton "Effacer le formatage".
- Qu'Impress fonctionne vraiment, de façon cohérente sans passer son temps à planter, bref qu'il devienne opérationnel pour qu'on puisse faire du travail professionnel. Ou alors qu'on le laisse tomber.
- Qu'une fonction équivalente à "Tableaux" d'Excel soit implémentée.
- Que le traitement des images soit amélioré.
- Que les copier-coller ne soient pas aussi bizarres.

Ce sont, je le crains de grandes améliorations, surtout concernant Impress.

Bon ben j'y vais aussi de mes demandes !

- raisonnable, je pense : pouvoir appliquer la fonction "compresser les
images" à l'ensemble des images d'un document en une seule opération.

- publipostage : performance, performance, performance... Je radote sur le
sujet depuis des années, mais au boulot nous avons un pc avec encore une
version openoffice 1.1.5 uniquement pour du publipostage "lourd". Le
paramétrage "base de données" de la branche 1.x était lourd et pénible ,
mais une fois en place ... ca roule avec des temps de réponse tout à fait
correct pour des publipostage de quelques milliers d'adresses... A partir de
la branche 2.x ... les performances se sont effondrées. Le paramétrage "base
de données" est bien plus simple ... mais une fusion dépassant quelques
centaines d'adresses met votre patience à rude épreuve. Ca commence pas très
vite ... et ca ralentit au fur et à mesure.

- publipostage : tant qu'on y est ... quelquechose de plus simple pour
l'utilisateur lambda pour les "paragraphes masqués" lorsqu'un paragraphe est
vide. Cas typique des blocs adresses avec certaines lignes vides : il faut
insérer une condition basée sur le nom du champ. C'est lourd pour un
utilisateur standard ... et pour peu qu'il relie la zone à une autre base de
données avec un nom de champ différent, il faut penser à enlever l'ancienne
condition ( invisible par défaut) et la remplacer par la nouvelle. Une
condition simple du style "ne pas imprimer si paragraphe vide" serait pas
mal !

- Afficher dans le navigateur une icône (ou dans une police de couleur différente) pour les images *liées*.

Une meilleure visibilité de la suite et de son évolution

ainsi, plutôt qu'une liste de commits pour chacune de versions, un tri de ces commits
     - ajouts de fonctionnalités
     - correction de bugs liés aux nouvelles fonctionnalités de cette version

     - corrections de régression vis-à-vis de la version à préciser

des versions de vie plus longues (une sur deux, une sur trois)

Quand on voit que la 4.1.4 a intégré près d'une centaine de correctifs divers. Que cette version est recommandée vis-à-vis de la 4.0.6.

que près de 80 sont déjà dans les tuyaux de la 4.1.5 on peut légitimement se poser la question de la qualité effective de 4.0.6 ou de la 4.1.4

ou alors, sérieusement décaler la RC2 de la RC1 pour la dernière version d'une branche, afin de laisser le temps d'intégrer des bugs très gênants ou des régressions sérieuses (plantage des tableaux d'impress, méli-mélo dans les styles d'impress)

(une trentaine de correctifs sont dans les tuyaux d'une hypothétique 4.0.7),

Joyeux Noël à tous

Pierre

Ne plus utiliser de javascript dans les sites openoffice.

Cordialement

Ne plus utiliser de Java dans LibreOffice :slight_smile:

Une demande concernant la liste.
Mettre un intitulé d'objet aux demandes d'aide par formulaire. Avec le système actuel, on est obligé d'ouvrir tous les fils pour savoir de quoi il retourne.

Bonne année à tous.

Micheline de Liège

Bonjour,

Une demande concernant la liste.
Mettre un intitulé d'objet aux demandes d'aide par formulaire. Avec le
système actuel, on est obligé d'ouvrir tous les fils pour savoir de quoi
il retourne.

+1

En plus cela ne respecte pas la netiquette.

Chaque nouveau sujet possède également un titre et celui-ci doit d'être précis et concis (ex. : Comparatif des souris Optiques et Laser, contre-ex. : Questions, Aidez moi).

https://fr.wikipedia.org/wiki/Netiquette#R.C3.A9ponse

Autre souhaits:
* fin de java dans LibreOffice.

* que Libreoffice et Apache OpenOffice finissent d'intégrer les derniers
éléments de l'ODF 1.2 (il en reste pour la 4.3:
https://wiki.documentfoundation.org/ReleaseNotes/4.3#Calc , j'ignore
pour la 4.4). Que l'ODF 1.2 passe le statu de norme ISO (comme l'est la
norme 1.0 qui est la norme ISO 26300:2006 amendé en 2012 pour la version
1.1 )

Paix et prospérité pour les développeurs et les contributeurs du
logiciels libres (pour les autres aussi, on ne va pas être sectaire).

J'en profite pour souhaiter une bonne année 2014.

Bon, comme tu sais, c'est pas vraiment le père Noël qui concocte
LireOffice mais une bande de petits lutins bénévoles pour la plupart qui
s'acharnent a améliorer, vérifier, traduire, documenter, etc...

Donc merci pour ta liste, mais si tu (et ceux qui y ont participé) ne
veux pas qu'elle reste lettre morte, voici ce qu'il faudrait maintenant :
- synthétiser ce fil et poster cette synthèse pour mémoire sur la liste
qa@fr
- analyser ce qui est bug et demande d'amélioration
- vérifier sur notre base de données de bug ce qui est déjà demandé et
au besoin le commenter
- ouvrir les nouvelles demandes d'amélioration ou bugs
- déterminer ce qui pourrait être une extension et en proposer sa
réalisation à la communauté.

Je crois que la dizaine de personnes à avoir participé pourrait
s'organiser et faire un groupe 'lettre au père Noël' afin de la pousser
jusqu'à l'atelier :slight_smile: Je suis prête à aider ceux qui le souhaiteront.

À bientôt
Sophie

Bonjour Pierre,

- Afficher dans le navigateur une icône (ou dans une police de couleur
différente) pour les images *liées*.

24 décembre, super j'ai le droit de rêver et d'y croire ....
Sans volonté de troller ou quoi ou quesse voici ma petite liste au père
noël

Une meilleure visibilité de la suite et de son évolution

ainsi, plutôt qu'une liste de commits pour chacune de versions, un tri
de ces commits
    - ajouts de fonctionnalités
    - correction de bugs liés aux nouvelles fonctionnalités de cette
version

    - corrections de régression vis-à-vis de la version à préciser

Je suis en train de faire en sorte qu'une issue de référence soit
ouverte pour chaque nouvelle fonctionnalité afin qu'on puisse la tester
et la documenter. Je profite de la migration de Bugzilla sur notre
propre système pour cela, et ensuite, il faudra contraindre les nouveaux
contributeurs à s'y mettre, ce qui n'est pas la plus petite partie.

des versions de vie plus longues (une sur deux, une sur trois)

Ce n'est tout simplement pas possible en raison du coût que cela
implique pour la communauté. Ceux qui ont besoin d'un support long
doivent le prendre auprès des entreprises qui le fournisse.

Quand on voit que la 4.1.4 a intégré près d'une centaine de correctifs
divers. Que cette version est recommandée vis-à-vis de la 4.0.6.

que près de 80 sont déjà dans les tuyaux de la 4.1.5 on peut
légitimement se poser la question de la qualité effective de 4.0.6 ou de
la 4.1.4

ou alors, sérieusement décaler la RC2 de la RC1 pour la dernière version
d'une branche, afin de laisser le temps d'intégrer des bugs très gênants
ou des régressions sérieuses (plantage des tableaux d'impress, méli-mélo
dans les styles d'impress)

Cela ne changera rien. Pour le mixage des styles dont je suis
responsable et que tu cites, ce sont des chaînes que je ne crois pas
avoir touché cette année, cela doit remonter à un moment donc. Ce qu'il
faut, c'est tester les versions bien avant la RC, dès les alphas et
favoriser son terrain de jeu : impress pour toi, math pour Didier,
etc... le fait que j'ai pu corriger juste avant le freeze de la 4.2.0
est grâce à Pierre-Yves et son analyse et j'ai donc pu vérifier que la
4.1.x était également impactée. Je ne maintiens plus la 4.0.x, mais
c'est possible que le bug soit dedans et y restera.

À bientôt
Sophie

Donc si on synthétise un peu :

*Writer *
— Faciliter le commencement de la numérotation à la deuxième page d’un document (sans passer par les styles).
— Bouton pour supprimer en 1 seul clic l’intégralité des styles et formatages direct sur un texte, paragraphe page.
— On puisse faire sa barre d’outils avec les styles utilisés, tous sans distinction de catégorie, et seulement ceux-là avec en plus la possibilité d’ajouter un bouton « Effacer le formatage ».
— Pouvoir appliquer la fonction « compresser les images » à l’ensemble des images d’un document en une seule opération.
--> Il y a une extension qui le fait, je crois
    *Publipostage:*
— Bouton activer/désactiver la prévisualisation
— Activer le système de navigation des enregistrements en prévisualisation
— Activer l’actualisation des enregistrements (sans passer par F4 avec un tableur comme base de données)

  *Styliste:*
— classement des styles de paragraphes par catégorie dans le styliste (avec le + le déploiement)
— Hiérarchie des styles de pages, au moins le format et les marges.

  *Tableau:*
— faciliter (btn) la suppression/ajout de cellule avec adaptation largeur
tableau (à ce jour Alt + Suppr/Inser (3 secondes) + flèche)

  *Impress*
— Qu’Impress fonctionne vraiment, de façon cohérente sans passer son temps à planter, bref qu’il devienne opérationnel pour qu’on puisse faire du travail professionnel. Ou alors qu’on le laisse tomber.
— Qu’une fonction équivalente à « Tableaux » d’Excel soit implémentée.
— Que le traitement des images soit amélioré.
— Que les copier-coller ne soient pas aussi bizarres.

*Publipostage*

- Performance, performance, performance... Je radote sur le sujet depuis des années, mais au boulot nous avons un pc avec encore une version OpenOffice 1.1.5 uniquement pour du publipostage « lourd ». Le paramétrage « base de données » de la branche 1.x était lourd et pénible , mais une fois en place... ça roule avec des temps de réponse tout à fait corrects pour des publipostages de quelques milliers d’adresses... À partir de la branche 2.x... les performances se sont effondrées. Le paramétrage « base de données » est bien plus simple... mais une fusion dépassant quelques centaines d’adresses met votre patience à rude épreuve. Ca commence pas très vite... et ça ralentit au fur et à mesure.
—Quelque chose de plus simple pour l’utilisateur lambda pour les « paragraphes masqués » lorsqu’un paragraphe est vide. Cas typique des blocs adresses avec certaines lignes vides : il faut insérer une condition basée sur le nom du champ. C’est lourd pour un utilisateur standard... et pour peu qu’il relie la zone à une autre base de données avec un nom de champ différent, il faut penser à enlever l’ancienne condition (invisible par défaut) et la remplacer par la nouvelle. Une condition simple du style « ne pas imprimer si paragraphe vide » serait pas mal !

*Navigateur*
— Afficher dans le navigateur une icône (ou dans une police de couleur différente) pour les images*liées*.

*QA/marketing*

— Une meilleure visibilité de la suite et de son évolution ainsi, plutôt qu’une liste de commits pour chacune de versions, un tri de ces commits
     — ajouts de fonctionnalités
     — correction de bugs liés aux nouvelles fonctionnalités de cette version
     — corrections de régression vis-à-vis de la version à préciser

— Des versions de vie plus longues (une sur deux, une sur trois)

* infrastructure *
— Ne plus utiliser de JavaScript dans les sites OpenOffice.
— Mettre un intitulé d’objet aux demandes d’aide par formulaire. Avec le système actuel, on est obligé d’ouvrir tous les fils pour savoir de quoi il retourne.

*Général*
— Ne plus utiliser de Java dans LibreOffice
--> c’est en cours je crois, déjà pas mal de code en moins et l’arrivé de Firebird SQL devrait bien réduire la dépendance java
— que LibreOffice et Apache OpenOffice finissent d’intégrer les derniers éléments de l’ODF 1.2

Reste à rechercher les bugs, et à remplir les demandes d’amélioration. pour ce qui est d’imrpess, je crois qu’il y en a déjà pas mal

Pierre

Bonjour Pierre,

- Afficher dans le navigateur une icône (ou dans une police de couleur
différente) pour les images *liées*.

24 décembre, super j'ai le droit de rêver et d'y croire ....
Sans volonté de troller ou quoi ou quesse voici ma petite liste au père
noël

Une meilleure visibilité de la suite et de son évolution

ainsi, plutôt qu'une liste de commits pour chacune de versions, un tri
de ces commits
     - ajouts de fonctionnalités
     - correction de bugs liés aux nouvelles fonctionnalités de cette
version

     - corrections de régression vis-à-vis de la version à préciser

Je suis en train de faire en sorte qu'une issue de référence soit
ouverte pour chaque nouvelle fonctionnalité afin qu'on puisse la tester
et la documenter. Je profite de la migration de Bugzilla sur notre
propre système pour cela, et ensuite, il faudra contraindre les nouveaux
contributeurs à s'y mettre, ce qui n'est pas la plus petite partie.

Je crois que le gros du boulot est déjà fait. Dans un bug, il y a le mot clé régression et la version identifiée de la régression. il ne reste plus qu'à mettre ça en forme dans un tableau avec un requête appropriée

des versions de vie plus longues (une sur deux, une sur trois)

Ce n'est tout simplement pas possible en raison du coût que cela
implique pour la communauté. Ceux qui ont besoin d'un support long
doivent le prendre auprès des entreprises qui le fournisse.

c'est donc un problème de choix, de priorité, pas une impossibilité

Est-il normal qu'actuellement il n'y ait pas de version téléchargeable de LibreOffice qui permettent de travailler avec des tableaux dans impress sans que ça plante toutes les 5 minutes ?

Si on répond oui, alors il faut l'afficher clairement "attention vous utilisez un logiciel à plantage aléatoire"

Si on répond non, alors il faut trouver une solution

Quand on voit que la 4.1.4 a intégré près d'une centaine de correctifs
divers. Que cette version est recommandée vis-à-vis de la 4.0.6.

que près de 80 sont déjà dans les tuyaux de la 4.1.5 on peut
légitimement se poser la question de la qualité effective de 4.0.6 ou de
la 4.1.4

ou alors, sérieusement décaler la RC2 de la RC1 pour la dernière version
d'une branche, afin de laisser le temps d'intégrer des bugs très gênants
ou des régressions sérieuses (plantage des tableaux d'impress, méli-mélo
dans les styles d'impress)

Cela ne changera rien. Pour le mixage des styles dont je suis
responsable et que tu cites, ce sont des chaînes que je ne crois pas
avoir touché cette année, cela doit remonter à un moment donc. Ce qu'il
faut, c'est tester les versions bien avant la RC, dès les alphas et
favoriser son terrain de jeu : impress pour toi, math pour Didier,
etc... le fait que j'ai pu corriger juste avant le freeze de la 4.2.0
est grâce à Pierre-Yves et son analyse et j'ai donc pu vérifier que la
4.1.x était également impactée. Je ne maintiens plus la 4.0.x, mais
c'est possible que le bug soit dedans et y restera.

Loin de moi l'idée je faire des reproches à des personnes, mais plutôt à un fonctionnement, une démarche qui, je crois amène une dégradation de la suite.

C'est pourquoi je propose des pistes pour améliorer la visibilité de la suite.

Savoir rapidement qu'elles sont les régressions identifiées pour une version, celles qui sont corrigées, les bugs des nvelles fonctionnalités.

les requêtes sur bugzilla, les MAB, c'est pour des spécialistes anglophones

J'ajouterai un souhait dans la gestion des bugs (donc le QA)

Quand un bug est rempli, il y a deux critères d'importance l'un va de highest à lowest, l'autre va de blocker à trivial /enhancement. je n'ai jamais bien compris à quoi ils servent
Il me semble que le premier devrait être rempli par un développeur qui connait un peu le code impacté par le bug. Il donne son avis sur la difficulté à résoudre le bug (sachant qu'il y a une part de subjectivité la de dans des fois ça paraitra compliqué et ce sera résolu en 5 min et inversement)

Le second devrait être rempli par un membre QA est donner son avis sur l'impact de la suite

Ainsi tous les bugs très impactant pour la suite et simples à résoudre devraient être résolus et être automatiquement ajoutés dans la MAB

(c'est peut être déjà comme ça que ça fonctionne, mais l'anglais et moi...)

Pierre

Bonjour Pierre,

- Afficher dans le navigateur une icône (ou dans une police de couleur
différente) pour les images *liées*.

24 décembre, super j'ai le droit de rêver et d'y croire ....
Sans volonté de troller ou quoi ou quesse voici ma petite liste au
père
noël

Une meilleure visibilité de la suite et de son évolution

ainsi, plutôt qu'une liste de commits pour chacune de versions, un tri
de ces commits
     - ajouts de fonctionnalités
     - correction de bugs liés aux nouvelles fonctionnalités de cette
version

     - corrections de régression vis-à-vis de la version à préciser

Je suis en train de faire en sorte qu'une issue de référence soit
ouverte pour chaque nouvelle fonctionnalité afin qu'on puisse la tester
et la documenter. Je profite de la migration de Bugzilla sur notre
propre système pour cela, et ensuite, il faudra contraindre les nouveaux
contributeurs à s'y mettre, ce qui n'est pas la plus petite partie.

Je crois que le gros du boulot est déjà fait. Dans un bug, il y a le mot
clé régression et la version identifiée de la régression. il ne reste
plus qu'à mettre ça en forme dans un tableau avec un requête appropriée

des versions de vie plus longues (une sur deux, une sur trois)

Ce n'est tout simplement pas possible en raison du coût que cela
implique pour la communauté. Ceux qui ont besoin d'un support long
doivent le prendre auprès des entreprises qui le fournisse.

c'est donc un problème de choix, de priorité, pas une impossibilité

Est-il normal qu'actuellement il n'y ait pas de version téléchargeable
de LibreOffice qui permettent de travailler avec des tableaux dans
impress sans que ça plante toutes les 5 minutes ?

Si on répond oui, alors il faut l'afficher clairement "attention vous
utilisez un logiciel à plantage aléatoire"

Si on répond non, alors il faut trouver une solution

répondre non serait faux puisqu'il y a toujours des plantages aléatoires
dans un logiciel. Par contre je peux implémenter des tests de non
régression dans Moztrap de façon à ce qui n'est pas dans les tests
automatiques le soit dans les tests manuels. Je l'ai fait pour le moment
pour Writer et Calc pas sur Impress c'est vrai, mais il faut aussi plus
de testeurs sur Moztrap...

Quand on voit que la 4.1.4 a intégré près d'une centaine de correctifs
divers. Que cette version est recommandée vis-à-vis de la 4.0.6.

que près de 80 sont déjà dans les tuyaux de la 4.1.5 on peut
légitimement se poser la question de la qualité effective de 4.0.6 ou de
la 4.1.4

ou alors, sérieusement décaler la RC2 de la RC1 pour la dernière version
d'une branche, afin de laisser le temps d'intégrer des bugs très gênants
ou des régressions sérieuses (plantage des tableaux d'impress, méli-mélo
dans les styles d'impress)

Cela ne changera rien. Pour le mixage des styles dont je suis
responsable et que tu cites, ce sont des chaînes que je ne crois pas
avoir touché cette année, cela doit remonter à un moment donc. Ce qu'il
faut, c'est tester les versions bien avant la RC, dès les alphas et
favoriser son terrain de jeu : impress pour toi, math pour Didier,
etc... le fait que j'ai pu corriger juste avant le freeze de la 4.2.0
est grâce à Pierre-Yves et son analyse et j'ai donc pu vérifier que la
4.1.x était également impactée. Je ne maintiens plus la 4.0.x, mais
c'est possible que le bug soit dedans et y restera.

Loin de moi l'idée je faire des reproches à des personnes, mais plutôt à
un fonctionnement, une démarche qui, je crois amène une dégradation de
la suite.

Je te répondais juste sur le process qui est le mien, donc que je
maîtrise, je ne me suis pas sentie attaquée :slight_smile: il faut que la suite soit
testée bien plus tôt qu'elle ne l'est actuellement et par bien plus de
monde qu'elle ne l'est actuellement aussi. Pour revenir à ce process
particulier, la localization FR est faite bénévolement par moi, donc la
nuit le plus souvent ou parfois le weekend entre ma famille, c'est
effectivement une source d'erreur non négligeable et qui peut impacter
lourdement la suite et son utilisation, comme tu en fais les frais
actuellement. Ce qui n'est pas normal, c'est que la correction
n'intervienne que dans la 4.1.4 alors que ce bug est présent depuis la
4.1.0. Plus de testeurs de mes bêtises auraient permis de les corriger
plus tôt :slight_smile:

C'est pourquoi je propose des pistes pour améliorer la visibilité de la
suite.

oui, c'est intéressant et je t'en remercie. Je ne peux que te répondre
que malheureusement nous ne sommes pas assez nombreux à faire de
l'assurance qualité, mais que nous faisons tout pour que cela
s'améliore. Et si j'avais un seul souhait pour 2014, ce serait de
trouver un développeur pour Moztrap et d'avoir enfin son
internationalisation.

Savoir rapidement qu'elles sont les régressions identifiées pour une
version, celles qui sont corrigées, les bugs des nvelles fonctionnalités.

c'est effectivement tracé mais en anglais uniquement pour les besoins du
projet QA international et des développeurs.

les requêtes sur bugzilla, les MAB, c'est pour des spécialistes anglophones

Il y a des possibilités de faire des tableaux et des graphs sur
Bugzilla, par exemple :
http://ur1.ca/g7wss
ou encore ce type de graph pour nous motiver à passer sous la barre des
800 bugs à confirmer cette semaine malgré les fêtes :
https://bugs.freedesktop.org/reports.cgi?product=LibreOffice&datasets=UNCONFIRMED
mais je suis d'accord qu'il faut connaître l'anglais pour se les réaliser.

À bientôt
Sophie

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.

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 de la dernière version d’une branche (un ou deux mois carrément. ceux qui veulent des versions bien stables peuvent attendre).

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)

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.

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

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 d'Impress, car je ne sais pas si c’est là la source des bugs que j’ai présenté sur la liste QA-fr et donc si je dois faire un rapport de bug

Pierre