Jean-Baptiste, Le Sun, 06 Jun 2010 14:07:42 +0200, Jean-Baptiste Faure <jbf.fa...@laposte.net> a écrit :
> Le 03.06.2010 09:12, Cédric Bosdonnat a écrit : > > Bonjour Bruno, > > > > Le mercredi 02 juin 2010 à 21:48 +0200, Bruno Friedmann a écrit : > > > >> C'est même souvent mieux, c'est mon cas avec openSUSE, > >> Comme c'est super facile de remonter les bugs chez eux, et > >> l'équipe en charge remonte upstream sur oogo. > > Je sais, je fait partie de cette equipe aussi ;) > > > > > >> Bon je parle et écris l'anglais : ce qui est souvent un frein pour > >> l'utilisateur de base. Mais très souvent c'est nécessaire, et en > >> plus il y a souvent des confirmations ou expérimentations > >> supplémentaires à faire. (et la ça dépasse souvent la compétence > >> de l'utilisateur lambda ... ) > > Merci beaucoup pour ton aide. N'hesite pas a motiver d'autres > > personnes de ton entourage pour mieux repartir le travail. > > > > JBF, Gilles: comment utiliser au mieux les outils du projet > > francophone pour lancer cette equipe? > > > > A bientot, > > > > > Bonjour Cédric et tous, > > Vous voudrez bien m'excuser d'avoir tardé à répondre mais j'étais en > déplacement cette semaine. > Tout d'abord je veux remercier Cédric pour cette excellente > initiative. Pour moi l'outil de base devrait être la liste qa-t...@fr > avec éventuellement des relais sur d...@fr. > Actuellement le travail de remontée des problèmes signalés sur > us...@fr n'est pas formalisé, il repose sur l'initiative de ceux qui > suivent la liste d'entraide. La difficulté est qu'il faut faire la > distinction entre ce qui est un bug entre la chaise et le clavier et > ce qui est possiblement un bug de OOo et donc demande quelques tests > plus approfondis. > > Je pense qu'une première étape pour constituer une telle équipe serait > de faire le point sur les participants intéressés avec les > informations suivantes : > - le ou les OS sur lesquels ils peuvent réaliser des tests > complémentaires avant de remonter un bug sur IZ > - le ou les modules qu'ils pratiquent le plus, voire même les > compétences inter-modules spécifiques, telles que le publipostage, > l'utilisation de documents maître, la liaison avec des données > externes, le déploiement de OOo, l'écriture de macro, etc. > - s'ils ont ou non le droit "canconfirm" sur IZ. > > Par ailleurs, afin de ne pas remonter des bugs déjà connus, il est > utile de se tenir au courant des nouveaux bugs rapportés sur IZ. Il > existe un fil RSS qui fournit la liste des nouveaux rapports de bugs > 2 fois par jour. On trouve ce fil sur le planet OOo > (http://planet.services.openoffice.org/) dont le lien est disponible > sur la page d'accueil du site FR. > > Sur le plan procédural, je pense qu'il y a deux étapes, la première > relève de sentinelles sur la liste us...@fr (mais aussi peut-être > ailleurs) qui d'une part détectent les possibles bugs et envoient une > alerte sur qa-t...@fr pour approfondissement et d'autre part informent > la liste us...@fr quand un bug déjà connu est rapporté qu'il s'agit en > effet d'un bug connu. La seconde étape se passerait plutôt sur > qa-t...@fr avec un travail de précision du scénario de reproduction du > défaut, une recherche de doublon sur IZ et enfin, si nécessaire, un > rapport sur IZ, confirmé par quelqu'un ayant le droit "canconfirm". > > Voilà mon point de vue pour le moment. Qu'en pensez-vous ? > > Bonne journée > JBF > Bonne idée. Ne pas oublier de bien classer les bug sur Linux selon la distro, c'est important pour la suite je crois... :) Charles. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
