Journal Gnome BugDay ce 21 juillet.

Posté par  (site web personnel, Mastodon) .
Étiquettes :
0
21
juil.
2005
Ce 21 juillet, à partir de +/- midi heure européenne, rendez-vous sur #bugs pour tous les utilisateurs de gnome parlant anglais.

http://live.gnome.org/Bugsquad_2fBugDays(...)


Une première tâche très utile aux développeurs est de trier tous les bugs UNCONFIRMED.

http://tinyurl.com/alndp(...)
http://tinyurl.com/ddtdo(...)

Comment trier ces bugs ?

C'est expliqué en détail :
http://developer.gnome.org/projects/bugsquad/triage/(...)
(lisez spécialement : http://developer.gnome.org/projects/bugsquad/triage/steps.html)(...)

Enfin, au début ou n'importe quand en cas de doute, demandez sur #bugs avant de faire une bêtise ! (à ce niveau là, j'ai d'ailleurs fait plus que ma part).

Deux outils indispensables :
Les réponses standards ( http://developer.gnome.org/projects/bugsquad/triage/steps.html(...) )
Le comparateur de traces ( http://bugzilla.gnome.org/dupfinder/simple-dup-finder.cgi(...) )

Coutumes : J'ai appris qu'il est de coutume, même si le rapport de bug semble foireux, de d'abord demander poliment plus d'informations et de marquer le bug comme "NEEDINFO". Lorsqu'on marque un bug comme "NEEDINFO", il est indispensable de se mettre en CC:.
Si un bug qui vous semble foireux (incomplet, non reproductible, très très ancien) reste en NEEDINFO pendant plus d'un mois, il est généralement fermé.


Alors, pour ce bugday, je vous lance un défi :
- Outre toutes les informations que vous pourriez ajouter, tout le travail de triage que vous allez faire, je met au défi chaque utilisateur de gnome qui lit ceci de fermer au moins un bug dans le bugzilla !
Fermer un bug peut se faire de différentes façon :
- Proposer un patch qui résout le bug (ok, le bug est pas fermé tout de suite, mais j'accepte cette solution)
- trouver un bug qui est le double d'un autre et le marquer comme doublon
- trouver un bug qui n'est vraiment plus d'actualité et/ou qui est en needinfo depuis un bon moment sans espoir d'avancement. (prendre conseil sur #bugs avant toute action de ce genre).
- trouver un bug qui ne se rapporte en fait pas à un logiciel Gnome, répondre selon la stock response appropriée et fermer le bug. (un conseil, cherchez les bugs openoffice ;-) )

Perso, je viens de passer 3h à trier des bugs, on voit pas le temps passer :-)
(ah oui, j'ai trouvé mon dup du jour et j'ai donc fermé un bug ;-) )


PS : à ceux qui ne seraient pas familiers avec le bug triaging et bugzilla, je conseille de demander d'abord des explications sur #irc et de lire la doc. Ensuite, n'hésitez pas à demander conseil à chaque action que vous faites.
Il vaut mieux poser plein de questions que de faire une connerie.

  • # pouvoir signaler un bug sur irc

    Posté par  (site web personnel) . Évalué à -1.

    Bien souvent l'utilisateur n' pas le temps ou la motivation pour passer 10 minutes a remplir des formulaires de bug sur un bugzilla.
    Par contre s'il est souvent sur irc et qu'il peut signaler son probleme vite fait il le fera quand meme.

    Si les projets qui ont leur chan IRC sont nombreux, les developpeurs qui prennent les bugs et suggestions sur IRC sont plus rares.

    Palme d'or du bugreport pour #spip sur freenode ( irc://irc.freenode.org#spip ) avec un record de correction dans le cvs en 22 minutes a partir du signalement du bug sur IRC.

    Palme d'argent à #mandrivafr sur le meme serveur, meme si ca a tendance à se dégrader.

    Le bugreport et autre feedback via IRC est une vraie chance pour le Libre Software, merci aux développeurs d'y être attentifs . . .

    "You have enemies? Good. That means you've stood up for something in your life." Winston Churchill

  • # Petit besoin de précision ...

    Posté par  (site web personnel) . Évalué à 1.

    Je suppose que #bugs est sur irc.gnome.org mais est ce bien le cas ?

  • # Décalage horaire...

    Posté par  . Évalué à -1.

    Un peu dommage que ce soit à midi heure européenne... Ca empeche pas mal de mon de participer. Ici (amérique du nord), avec 6h de décalage, ca donne 6h du matin... Autant dire que c'est pas immaginable de participer :(

    Mais l'idée est quand même pas mal bonne. Est-ce quelque chose qui se fait régulierement?

    JMS

    • [^] # Re: Décalage horaire...

      Posté par  . Évalué à 0.

      C'était pas à midi en France, encore moins en Europe. ploum est allé un peu vite dans la retranscription.

      Comme on peut le voir ici : http://gnomedesktop.org/node/2325(...) , c'était à 14h en France. Et donc 8h du matin sur la côte est des US.

    • [^] # Re: Décalage horaire...

      Posté par  . Évalué à 1.

      Stop ! L'heure est passée, nous refusons désormais tout rapport de bugs.

      C'est un jour comme un autre, sauf que les différentes ressources se coordonnent pour inciter les utilisateurs à participer un peu en testant des logiciels et en fournissant des informations.

      Je vois quelqu'un se plaindre qu'il faut 10minutes pour remplir un bugzilla : c'est faux. Ça prend bien moins que ça. En tout cas c'est bien plus rapide que de passer l'aprèm à trouver la bonne personne à qui larborieusement expliquer le problème, personne qui concluera par "ouvre un bugzilla, s'il te plait" :)
      Y a pas de problème si le rapport original est incomplet ou peu précis : la création d'un compte prends quelques instants et après on est avertit par email des évolutions de la discussion du bug. On peut donc fournir plus d'infos facilement. C'est facile. Après si on trouve que ce n'est pas le cas, je pense que c'est que de toutes façons, on manque de motivation sincère. Si c'est pour se vider les poumons, ça sert pas à grand chose.

      Deux tâches simples :
      - confirmer des bugs : suffit de se promener sur le bugzilla de son appli préférée, et de lire quelques rapports. Un simple "J'arrive à reproduire avec la nouvelle version x.y.z" est déjà très utile ...
      - rapporter des bugs de traduction : suffit de créer un bug sur l'appli (mot clef "I18N") ou bien pour l10n (product "l'appli") et de mentionner les problèmes.

      Faut pas avoir peur de bugzilla, c'est vachement utilisé, et suivre le bugzilla de son appli préféré, ça permet de se tenir au courant des évolutions, puisque beaucoup de nouvelles fonctionalités sont issues de bugs ...


      Ouala, envoyez des rapports de bugs. Personne n'est parfait : on ne peut pas tester exhaustivement une application ou se rendre compte des problèmes des autres. Suffit de prendre son clavier pour se faire entendre tous les jours de l'année.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.