Depuis quelques jours, j'ai abandonné mon Firefox 2 et mes 27 extensions pour passer aux compilations nocturnes de Firefox 3. Pourquoi? Un billet de Gerv m'a interpellé : Why I Can't Test 3.0b1
Gerv (qui a souvent des idées brillantes au passage) a 100% raison dans cet article, les mozilliens de longue date qui étaient accros aux 'nightlies' sont devenus tellement dépendants de leurs extensions qu'ils ne testent plus les bêtas et je pense que c'est une des raisons du retard qu'on a pris pour Firefox 3. On reçoit toujours énormément de feedback sur Bugzilla, les mozilliens de longue date continuent de tester les alphas et betas quelques jours quand elles sortent, mais ils ne l'utilisent plus comme navigateur principal. La différence entre un rapport de bug d'un utilisateur occasionnel et un rapport de bug d'un mozillien de longue date c'est la qualité de ce rapport. On sait remplir un bug, vérifier si ce n'est pas déjà dans la base de données, expliquer comment le reproduire, utiliser les bons mots clefs qui permettront de le retrouver dans les recherches, lui assigner la priorité qu'il convient, éventuellement on peut même mettre en copie le développeur qui saura le réparer tout simplement parce qu'on sait qui travaille sur quoi.
Je suis donc revenu à mes vieilles habitudes, je télécharge quotidiennement la compilation de la veille (en version française, ça c'est cool :) ), j'ai dans ma barre personnelle un lien vers les derniers rapports de bugs sur le tronc histoire de jeter un œil et de participer un peu au tri des bugs actuels et si quelque chose ne fonctionne pas, je rapporte.
J'ai déjà fait 5 rapports de bugs, l'un d'eux est invalide (bug 406404) car c'est un bug du lecteur RSS externe (liferea) que j'ai dû interfacer avec Firefox 3 pour remplacer mon bon vieux Sage (et la bonne nouvelle est que Liferea est maintenant au courant et va le réparer pour la prochaine version), un est résolu puisqu'il s'agit d'un bug graphique mineur sur un de nos sites et j'ai fourni le patch (bug 406399) , un autre sur mozilla.com est à traiter avec mes collègues de la localisation quand on aura le temps (bug 406400), et enfin deux sont à mon avis sérieux et affectent le fonctionnement de la barre d'adresse (bug 406690, bug 406360).
Si vous êtes un mozillien de longue date et n'avez pas peur des nocturnes, je vous engage à faire de même. Si vous êtes juste un testeur occasionnel, un bon moyen d'aider est de regarder les bugs ouverts, surtout les bugs marqués 'linux' et de tester sous Windows ou Mac si le bug vous affecte aussi, si c'est le cas indiquez-le dans les commentaires. C'est un moyen simple et rapide d'améliorer la qualité des rapports.
Commentaires
Je comprends ton billet et je ne peux que l'approuver. Personnellement, je fais compiler quasi-quotidiennement le code source du tronc pour ma Ubuntu 7.10 AMD64, car il n'existe pas encore en version 64 bits :(
Cela m'a permis de rapporter un ou deux bugs lié à la version 64 bits, surtout lié à l'utilisation de Cairo, un crash dans le "drag and drop".
Il faudrait écrire une article sur "Comment bien rapporter un bug ?" et "Comment participer au QA test day". Si quelqu'un qui en a les compétences en a aussi le temps qu'il n'hésite pas :)
En fait le truc ça serait surtout que ces mozilliens de longue date fassent pression auprès des auteurs d'extensions pour leur dire soit "ça marche parfaitement avec la v3 il faut mettre à jour l'info de compatibilité", soit "j'ai remarqué tel problème, quand est-ce que vous faites quelquechose pour le corriger ?".
Car en fin de compte c'est surtout les incompatiblité des extensions qui vonthésiter à faire la transition.
Et puis aussi, je crois que les versions qui manquent le plus cruellement de test, ce sont les correctifs de sécurité sur les versions stables.
Les deux dernières versions sorties dans un cycle normal la 2.0.0.8 et la 2.0.0.10 étaient chacune suffisament peu stable pour imposer la sortie d'un correctif immédiatement après (2.0.0.9 et 2.0.0.11).
->jmdesp, concernant les auteurs d'extensions, Mozilla contacte les auteurs des extensions les plus populaires et on réfléchit sur l'organisation d'opération de mises à jour des extensions (genre on fait une journée sur IRC dédiée uniquement à ça). Mais il est évident que ça ne peut pas se faire en un coup de cuiller à pot, rien que sur AMO il y a 4000 extensions.
Concernant le test des versions 2.x, tu as partiellement raison, mais c'est un parti pris de Mozilla de privilégier la résolution la plus rapide possible aux failles de sécurité au risque d'introduire des régressions dans les fonctionnalités de Firefox. Je suis le premier à être fatigué de ces mises à jour rapprochées, car lorsque les utilisateurs râlent pour avoir dû cliquer deux fois sur le panneau de mise à jour dans la semaine, pour moi ça veut dire des nuits de travail. Malheureusement, même si on essaye de faire le maximum de tests avant une mise à jour, les régressions arrivent tout de même.