LpSolit’s blog (original, isn’t it?)

While talking with gerv and justdave on IRC about the Committer’s agreement and asking whether MoCo was paying the stamp back, I suddently got a (bright?) idea: why not advertise Firefox, Thunderbird, Calendar, etc… by printing their logo on stamps? The only problem is that you cannot create your own stamps as you want. But this would be a cool way to bring Firefox & co. in all houses.

PS: if a chief of some post offices is reading this blog and you had no idea what to print in your next set of stamps, now you have one.

After reading Kairo’s article about bugs triaged in Seamonkey these last few weeks, I wanted to do a quick comparison between main products released by Mozilla: Firefox, Thunderbird, Seamonkey, Camino, Bugzilla, Calendar, and I also included Core and Toolkit. The comparison is interesting, as you can see below (click the image to make it larger… and readable).

As you can see, the two popular products of Mozilla, Firefox and Thunderbird, have many unconfirmed bugs. There are as many unconfirmed bugs as fixed bugs. This surprised me a bit when you know that with such a wide userbase and the QA team, bugs should become confirmed pretty quickly… or quickly be triaged as invalid or wontfix. Maybe are these products so popular that bugs are being filed much faster than they are resolved? I don’t know (someone more involved in these two products would know more).

The other six “products” (products as defined in Bugzilla) have a pretty similar behavior: only a few unconfirmed bugs, and two to three times more fixed bugs than open bugs (bugs marked as ASSIGNED and REOPENED have not been included as they are negligible compared to bugs marked as NEW). Does it mean triaging is more efficient and bugs fixed more quickly in these products, or does it mean these products are less popular, giving more time to developer teams to triage and fix bugs?

Anyway, my goal is not to say who is good and who isn’t in triaging and fixing bugs quickly. I just thought this graph was interesting. You are free to interpret it as you want.

Cela nous a pris beaucoup de temps, mais les nouvelles versions de Bugzilla sont enfin disponibles. 4 mois après la version stable 3.0.3 et 3 mois après notre dernière version en cours de développement 3.1.3, les versions 3.0.4 (stable), 3.1.4 (développement, mais déjà de bonne qualité), 2.22.4 et 2.20.6 sont enfin sorties. Ce temps particulièrement long entre nos versions de développement est dû au grand nombre de régressions et de fonctionnalités inachevées présentes dans la version 3.1.3, ce qui nous a pris passablement de temps et d’énergie à résoudre (surtout quand le problème provenait de modules Perl externes à Bugzilla). Mais l’attente en valait la peine!

Je résume:

Bugzilla 3.1.4 est notre dernière version de développement avant la sortie de la version 3.2 RC1. Par rapport à la version 3.1.3, celle-ci est nettement plus stable et utilisable. Cela ne veut pas dire qu’elle est sans erreur aucune, mais elle est déjà d’une très bonne qualité et pourrait presque être recommandée. Je dis “presque”, parce qu’elle n’a pas encore passé les tests de l’équipe qualité, l’attention ayant été portée sur la version stable 3.0.4. Mais comme toutes les versions “Release Candidates”, la 3.2 RC1 sera testée avec davantage de soins avant sa sortie. Parmi les changements et améliorations les plus notables, je peux citer la nouvelle interface lors de l’édition de bug (show_bug.cgi pour les intimes). Cette interface est censée être plus intuitive, mieux pensée… bref, plus mieux bien. Notamment, changer le statut d’un bug (NEW, ASSIGNED, RESOLVED, …) ainsi que sa résolution (FIXED, INVALID, WONTFIX, …) sont désormais déconnectés de l’assignation d’un bug, c’est-à-dire que vous pouvez dorénavant changer la personne assignée à un bug sans réouvrir le bug (par exemple). C’est un sacré plus par rapport aux versions 3.0.x. De même, les statuts sont désormais affichés dans une liste déroulante au lieu de devoir cliquer sur un bouton dans une liste difficile à utiliser.

Parmi les nouveautés de la version 3.1.4, relevons le support de l’authentification avec SMTP! Également, Bugzilla a été complètement basculé en mode UTF-8, y compris au niveau de la base de données MySQL, PostgreSQL, Oracle, ce qui nous a valu quelques irritations en voyant certains modules supporter l’encodage UTF-8 de manière misérable. Mais il semble que nous ayons éteint les derniers foyers. Si vous détectez de nouveaux départs de feu, merci d’informer notre équipe de pompiers en rapportant votre bug sur bugzilla.mozilla.org.

Bugzilla 3.0.4 est officiellement notre dernière version stable et est celle qui devrait être utilisée dans les missions critiques. Elle a subi plein de petites améliorations pour rendre la vie encore meilleure. La liste des principaux changements est disponible en anglais ici. Tout comme les autres versions sorties aujourd’hui, elle comporte également un certain nombre de bugs de sécurité résolus.

Enfin, les versions 2.22.4 et 2.20.6 sont également disponibles pour tout ceux qui utilisent encore ces anciennes versions et qui, pour des raisons diverses, ne peuvent pas installer la version 3.0.4. Mais le passage à la version 3.0.4 (voire à la version 3.1.4 pour les plus téméraires) est vivement recommandé, surtout que nous allons stopper le support de la série 2.20.x dès que la version 3.2 finale sera disponible.

Voilà, pour plus de détails, visitez notre site www.bugzilla.org.

==

Now for english speakers: You have all the information you want on www.bugzilla.org already, so all I will say is that Bugzilla 3.1.4 (development snapshot, last release before 3.2 RC1), 3.0.4 (latest stable release, recommended), 2.22.4 and 2.20.6 (both old stable releases) have been released today! If you can read french, read above, else read the release notes on the bugzilla.org website.

Maybe you didn’t know, but Bugzilla also has language packs available. Not all of them are up-to-date, but 6 languages are currently available for the latest stable release (Bugzilla 3.0.3): en, de, fr, ru, be, bg. I set up an installation with all these language packs installed, so that you can easily play with it and see how Bugzilla looks like in your preferred language. Bugzilla will query your web browser to display pages in the right language, so no need to look for a link somewhere in the page to change the language, there is none (yet). If you have an account there, you can edit your user preferences and select the language which should be used for email notifications. If you see weird behaviors, visit bug 405946 before reporting any new bug related to emails. And if you find a bug in a template, please report it to its author. The Bugzilla team is not responsible for these l10n packs.

–

Peut-être ne le saviez-vous pas, mais Bugzilla existe également en différentes langues. Toutes ne sont pas à jour, mais la dernière version stable de Bugzilla (3.0.3) est actuellement disponible en 6 langues: en (anglais), de (allemand), fr (français), ru (russe), be (biélorusse), bg (bulgare). J’ai mis sur pied une installation avec ces 6 langues disponibles pour que vous puissiez jouer avec et observer comment Bugzilla se présente dans votre langue préférée. Bugzilla questionne votre navigateur web directement afin de déterminer dans quelle langue afficher les pages. Il est donc inutile de chercher un lien dans la page pour changer la langue; il n’y en a pas (encore). Si vous avez un compte sur cette installation, vous pouvez éditer vos préférences utilisateurs et sélectionner la langue dans laquelle vous souhaitez recevoir vos emails. Si vous constatez un comportement étrange, visitez d’abord le bug 405946 avant de reporter un nouveau bug concernant les emails. Et si vous remarquez une erreur dans l’une des pages, reporte-là à son auteur. L’équipe Bugzilla n’est pas responsable des pages traduites.

Almost one year after we reopened the trunk for development, we are freezing again to prepare Bugzilla 3.2 RC1. (Almost!) all major enhancements we wanted for 3.2 have been implemented and so we are going to debug the code which suffered many regressions in the past few months due to heavy changes we made. It’s probably the first time we changed the code so much, but it should now be much easier to read and to extend. We released Bugzilla 3.1.3 a few days ago, which is mostly feature-complete (a few late minute patches are going to land this week) and has a new UI when editing bugs. The main missing feature in Bugzilla 3.2 will be the ability to update bugs using our WebService interface (a.k.a XML-RPC). The main reason to refactor the code in process_bug.cgi was to implement this API, but it has been decided that we were late enough to not hold the release on it. Yes, I know; all of you who planned to upgrade to 3.2 to have this API will finally have to wait for the next release, Bugzilla 4.0, which shouldn’t be available before early next year.

I suggest you download and test Bugzilla 3.1.3 as much as possible and report bugs you find to bugzilla.mozilla.org. There are several known bugs which have to be fixed before we release 3.2 RC1, but there are probably more bugs hidden somewhere and we would love to know about them before the release.

On December 4, 2007, Bugzilla developers got a great email from Melissa Shapiro (Press Release manager at Mozilla Corp.) telling us that Bugzilla won two awards from Software Test & Performance: one for Free Test/Performance Winner and the other for Defect/Issue Management Winner.

That’s definitely a great news and these awards are an acknowledgment of the hard work Bugzilla developers do and show that Bugzilla as a free and open-source software is able to compete with costly commercial products.

Grâce au dur labeur de mkanat (Bugzilla) et xiaoou (Oracle Corp.), Bugzilla supporte à présent Oracle en plus de MySQL et PostgreSQL. Le support d’Oracle est au stade expérimental alors soyez prudent en l’utilisant comme serveur de base de données. Si vous découvrez un problème avec Oracle, n’hésitez pas à le reporter. Notez que Oracle nécessite le code actuel disponible via CVS, ou patientez jusqu’à la sortie de Bugzilla 3.1.3 qui devrait être prochainement disponible (d’ici 2 semaines si tout va bien).

—

Thanks to the hard work of mkanat (Bugzilla) and xiaoou (Oracle Corp.), Bugzilla now supports Oracle as well as MySQL and PostgreSQL. Oracle support is still experimental, so be careful when using it. If you find any problem when using Oracle, do not hesitate to file a bug. Note that Oracle requires the current code from CVS, or wait for Bugzilla 3.1.3 which should be released in the coming days (maybe 2 weeks or so).

Voilà un certain temps que je n’ai plus donné de nouvelles concernant le développement de Bugzilla. Je vous propose donc de vous donner deux infos majeures:

• Tout d’abord, il est désormais possible de soutenir financièrement le projet Bugzilla grâce à cette page de dons. C’est tout nouveau, tout neuf, ça vient de sortir. L’idée est de se servir de cet argent pour financer certains travaux ou achats servant au projet lui-même (et non de se financer des vacances au soleil). Donc si vous souhaitez contribuer au projet Bugzilla mais que vous n’êtes ni un développeur, ni un beta-testeur, voilà une bonne idée d’apporter votre pierre à l’édifice.
• Concernant la sortie prochaine de Bugzilla3.2, sachez que la route est encore longue, mais nous progressons. Nous avons actuellement une douzaine de bugs marqués comme “bloqueurs” pour la sortie de Bugzilla 3.2, mais près de la moitié est en phase d’être résolue dans un délai relativement court. Cela ne veut pas dire que nous n’acceptons pas d’autres contributions. Le code n’est pas encore limité à cette liste et ne devrait pas l’être avant Noël, probablement. Donc si vous voulez voir quelque chose de particulier implémenté dans Bugzilla 3.2, il est temps de se manifester (notamment en écrivant des patches, pas des requêtes!). Notez qu’il y aura tout d’abord la sortie de Bugzilla 3.1.3, aux alentours de Nouvel-An, pour les développeurs principalement; cette version étant relativement instable. Suivra la sortie de Bugzilla 3.2 RC1 au début de l’an prochain et éventuellement 3.2 RC2 suivant la qualité et le retour de la RC1. Donc il reste plusieurs mois de développement avant de voir la sortie de Bugzilla 3.2. Cette sortie signifiera par ailleurs la fin du support de la version 2.20.x.

—

I didn’t give any new information about Bugzilla for a long time now. Here are two important ones:

• First of all, it’s now possible to make a donation to the Bugzilla project. This way to contribute is new and will help us to spend money on some Bugzilla-related works. So if you want to support Bugzilla but you are neither a developer nor a tester, here is a nice way to contribute!
• About the release of Bugzilla 3.2, we still have a lot of work to do, but we are doing good progress. There is currently a list of a dozen of blockers, and half of them are very close to being fixed.We still accept patches for bugs not being in this list as the code is not yet frozen. We will probably freeze around Christmas after what we will only accept bug fixes for Bugzilla 3.2. So if you want to see a new feature being implemented in 3.2, you have to hurry up. Note that we will first release Bugzilla 3.1.3, probably around New Year. This release will mainly be for developers as it will still be relatively unstable. Then, we will release Bugzilla 3.2 RC1 early next year and based on its quality and feedback, we will either release a second release candidate or Bugzilla 3.2 final. So there are several months left before the next stable release. This release will also mean the end of life of the Bugzilla 2.20.x branch.

So I finally decided to upgrade my Mandriva Linux 2007.1 installation to the new 2008.0 release. I expected the upgrade to be quick and painless, but it was the opposite. Not only the upgrade failed for some unknown reason, but before it started to fail, the “remaining time” field was displaying “07:03″. I first thought “7 minutes and 3 seconds”, but after an hour or so, I realized it meant “7 hours and 3 minutes”. Arghhh!!! So I went back watching TV (fortunately, there were two episodes of NCIS at that time). While giving a quick look at my PC, I realized a message was displayed informing me it couldn’t install cryptsetup. WTF??? I first clicked “try again”, but the same error came back. Of course, clicking “pass” didn’t help as many other RPMs couldn’t be installed, probably due to the missing RPM. So I rebooted the system, tried again, but now selecting as few packages as possible, to have at least a minimal installation to work with. Again unsuccessful, but now due to another missing RPM.

So I decided to do a fresh install instead of a 7 hours-long non-working upgrade. Selecting KDE as my default environment, it started installing RPMs again, now with a “remaining time” field of 1 hour only. *Much* better! Unfortunately, it was now complaining that it couldn’t install glibc (despite it installed cryptsetup successfully this time). Again another try, but now selecting as few RPMs as possible (avoiding KDE as it failed in my previous attempt). Same result: a package couldn’t be installed.

Fortunately, I have a dual boot and I started my Windows 2000 partition to download some additional ISO images. OpenSUSE 10.3, Fedora 8 Test 3, and Mandriva Linux 2008.0 mini (instead of the DVD ISO which I burnt for nothing as all my attempts above failed). I first wanted to test them in VirtualBox to decide which one to use to reinstall Linux, but they all failed at some point. Maybe Linux doesn’t like VirtualBox, or my system is so slow trying to run both Windows 2000 and Linux at the same time that it was in fact very slow, much slower than what I could accept. So I gave Mandriva another (and ultimate) chance and burnt the mini CD ISO. The UI let me choose between KDE, GNOME and IceWM. I selected KDE, but after the installation succeeded (finally!), I realized I was seeing IceWM. The reason was that KDE is not available on the mini CD ISO. So why letting me select it??

Well, I could at least configure rpmdrake to download missing packages from the web. But as usual, it first tries to get missing RPMs from your installation disk before downloading them, which is fine. But it was unable to find it! rpmdrake was indeed looking at /media/cdrom2, but this path was invalid. So I edited the path to look at /media/dvd but it was still ignoring my change, still asking for /media/cdrom2. So I edited /etc/fstab itself, and rpmdrake was now happy and could find /media/dvd.

I’m using Linux for 8 years now, among which 4-5 years using Mandrake/Mandriva. I always had problems installing a fresh new copy, and all upgrades failed as far as I can remember. I hoped this time the upgrade would work correctly. Sadness…

Now I understand why end-users still use Windows: it just works! Maybe Windows has many cons, but I never had any problem installing it. And I have never been so happy to have Windows 2000 still installed on my PC. I hesitated a few weeks ago to use the whole HD for Linux only, and keep Windows 2000 in a virtual box. But after this irritating and frustrating experience, I decided I would never do so. Windows 2000 will remain on my PC for a long time, despite I boot my system on Linux 99.9% of the time.

I could also tell you how Mandriva 2008.0 decided to ignore my SoundBlaster 4.1 sound card, falling back to the one installed on my motherboard, how it ate my menu bar, how it slowed down my web experience by waiting 10-15 seconds before starting loading any web page (the fix is to add “install ipv6 /bin/true” to /etc/modprobe.conf, so why not doing it by default?), etc… but I think you got the point.

You may wonder who are fixing the most bugs in the Bugzilla product these days? Below can you see the number of Bugzilla bugs fixed by the 5 most active Bugzilla developers as well as the total of bugs fixed by all other contributors grouped together (click the image to see a bigger graph).

Max (mkanat) and myself (LpSolit) are by far the two most active developers for quite a long time now, with Josh (timeless), Marc (wurblzap) and Olav (bkor) a bit behind. This doesn’t mean other contributions are negligible; they are of the same order of magnitude as Max or my own contributions, which is great! Nevertheless, I have to admit I would be pretty excited to see some new “hyperactive” contributors so that I don’t have the feeling that 2 or 3 developers only are doing 50% or more of the work.

We had an interesting Bugzilla meeting yesterday about parameters which are not important or used enough to stay in Bugzilla, to cleanup the code a bit and to make Bugzilla configuration easier. The results of the discussion are available on wiki. If you disagree with some removals suggested there, you have one month (till our next Bugzilla meeting on October 2) to let us know why we should keep them. Then we will validate these changes and start removing them. Note that this won’t affect Bugzilla 3.0.x and older; but only Bugzilla 3.2 and newer.

We know some given parameter always seems to be the most important one for some of you, and which we should in no way remove (else the parameter wouldn’t have been implemented). But at some point, we have to decide what is important enough to stay (or get implemented) and what is too specific to a single case to remain here. We will as much as possible take the best decision for those we decide to remove, i.e. hardcode them to their best value. In some cases (cookiepath, docs_urlbase, sslbase, timezone, maxpatchsize), this means setting them based on the value of some other fields. In some other cases (mostfreqthreshold, quicksearch_comment_cutoff), we will replace them by a constant which can still be configured by editing Constants.pm.

—

Nous avons eu une très intéressante réunion hier concernant Bugzilla à propos des paramètres existants dans Bugzilla qui ne sont pas suffisamment importants ou utiles pour rester présents, l’idée étant de nettoyer le code quelque peu et de rendre la configuration de Bugzilla plus facile en supprimant ce qui n’est pas primordial. Le résultat de la discussion est disponible sur wiki. Si vous n’êtes pas d’accord avec certaines suppressions proposées, faites-le nous savoir dans le mois à venir, avant notre prochaine réunion Bugzilla le 2 octobre prochain, et en expliquant pourquoi il est essentiel de conserver tel ou tel paramètre. Passé cette date, nous allons valider la liste et commencer à retirer les paramètres susmentionnés. Notez que Bugzilla 3.0.x et antérieures ne sont pas concernées par ces changements, mais uniquement Bugzilla 3.2 et suivantes.

Nous savons que certains paramètres sont vus comme les plus importants pour certains d’entre vous (sinon ces paramètres n’auraient pas été implémentés), mais à partir d’un moment, il devient nécessaire de trier entre ce qui est réellement utile au bon fonctionnement de Bugzilla et ce qui est superflu et ne fait que compliquer la gestion de Bugzilla. Nous allons dans la mesure du possible faire les meilleurs choix possibles concernant la valeur à conserver pour les paramètres supprimés. Dans certains cas (cookiepath, docs_urlbase, sslbase, timezone, maxpatchsize), cela signifie se servir d’autres paramètres pour définir ces valeurs. Ou encore les remplacer par une constante qu’il sera possible de modifier dans le fichier Constants.pm (mostfreqthreshold, quicksearch_comment_cutoff).

Today, I tried to view a PDF file from within Firefox thanks to the Adobe Reader 7.0 plugin, but I couldn’t understand why it took so long to load the PDF. I first thought it was a big file, but Firefox was completely frozen for more than one minute. I was expecting that even if this was a large file, Firefox should still be responsive and that the navigation in other tabs should still work. When I looked at my shell window to kill the Firefox process, I realized the window was full of “expr: syntax error” error messages. Was the PDF file corrupted or was it a bug in Firefox? None of them! This was a bug in acroread itself as running it from the shell with no file specified was throwing exactly the same error. So why today and not these last few months?? The reason seems to be that Mandriva Linux 2007.1 released some updates for libgtk-x11 a few days ago and acroread was now failing. Fortunately, the fix is trivial and acroread (and Firefox using the Adobe plugin) is working fine again! So if you are running Firefox on Linux and use the Adobe plugin to view PDF files and wonder why nothing happens, this may be the reason.

Bugzilla 3.0.1, la première mise à jour de Bugzilla 3.0 depuis sa sortie le 9 mai dernier (fixant notamment 3 bugs de sécurité) et Bugzilla 3.1.1, la première version de développement allant mener à la version 3.2 prévue au début 2008, sont sorties aujourd’hui même. Elles sont accompagnées des versions 2.22.3 et 2.20.5 qui fixent quelques problèmes dans les versions plus anciennes de Bugzilla. Les utilisateurs de PostgreSQL en particulier apprécieront. Plus d’informations sont disponibles sur le site de Bugzilla.

Petite statistique intéressante: à ce jour, Bugzilla 3.0 a été téléchargé 138′106 fois, mais de 45′024 adresses IP différentes. Cherchez l’erreur!

–

Bugzilla 3.0.1, the first update for Bugzilla 3.0 since its release on May 9 (fixing among others 3 security bugs), and Bugzilla 3.1.1, the first development snapshot of the future 3.2 version expected early next year, have both been released today. Also released are Bugzilla 2.22.3 and 2.20.5 which fix some bugs in older versions of Bugzilla. PostgreSQL users will appreciate. More information are available on the Bugzilla website.

For the record: Bugzilla 3.0 has been downloaded 138,106 times, but from 45,024 different IP addresses. What’s wrong??

We are going to implement a new skin in Bugzilla 3.2. You can see it applied on landfill. We are ready to commit it into CVS, but before doing that, we need a name for this new skin.

What would you suggest? So far, “Melancholy”, “Twilight” and “Desolation” have been suggested on IRC. Which one do you prefer? Do you have a better idea? Let us know.

PS: Note that the default skin will remain the one you already know and which we had till now. This new skin will be available as an alternate one from your user preferences (the “Preferences” link in your footer on b.m.o) so that everyone is free to choose the skin he prefers.

Till the previous Tinderstatus release (0.2.3), the tinderboxen to watch were hardcoded and you had to edit some files manually to customize the list. In the latest release (0.2.4), you now have a UI which lets you select which trees to watch, and the status icon appearing in your status bar is updated immediately; no need to restart Firefox. If the tree you want to watch is not in the list, all you have to do is to add it to the extensions.tinderstatus.fullList pref in about:config. The list displayed in the UI will be refreshed with this new tree included and all you have to do is to select it to immediately see its status. Definitely a huge improvement over the previous release. Congrats to standard8 and myk for this release!

Bugzilla 3.0 est enfin disponible en version française! Le travail de traduction de longue haleine de Cédric Corazza, de l’équipe French Mozilla, permet ainsi d’avoir une quatrième langue disponible pour la version 3.0, après l’anglais, l’allemand et le russe.

Un grand bravo à Cédric pour avoir osé affronter cette tâche loin d’être simple. Vous pouvez regarder à quoi ressemble la version française sur cette version de démonstration.

—

Bugzilla 3.0 is now also available in french! Thanks to the hard work from Cédric Corazza of the FrenchMozilla team, Bugzilla 3.0 is now available in english, german, russian and french.

Congratulations to Cédric, this wasn’t an easy task. An installation with the french package installed is available on landfill.

Lors de notre dernier meeting Bugzilla mardi dernier (10 juillet 2007), justdave a annoncé que Bugzilla 3.0 avait été téléchargé 86′060 fois depuis sa sortie le 9 mai dernier. Presque 100′000 téléchargements en 2 mois est un excellent score! Heureux de constater que les utilisateurs aiment notre produit.

–

At our last Bugzilla meeting last Tuesday (July 10th, 2007), justdave announced Bugzilla 3.0 has been downloaded 86,060 times since its release on May 9. Almost 100,000 downloads in 2 months is a pretty great score! Happy to see people like our product.

Testopia 1.3 est enfin sortie! Cette version est compatible avec Bugzilla 3.0 et fonctionne également avec PostgreSQL et mod_perl (et pas uniquement avec MySQL comme l’étaient les versions antérieures à 1.2.1).

Pour ceux qui ne connaissent pas (encore) Testopia, sachez qu’il s’agit d’un programme se greffant sur Bugzilla (via un patch qu’il s’agit d’appliquer sur le code de Bugzilla) et qui permet d’étendre ses fonctionnalités, plus exactement de lui permettre de gérer les tests faits sur tel ou tel produit. Vous pouvez ainsi définir une liste de tests à réaliser avant de sortir une nouvelle version d’un produit, exécuter ces tests manuellement ou automatiquement (ça, ce n’est pas Testopia qui les exécute; lui se contente de gérer les résultats de ces tests) et rentrer le résultat de ces tests dans Testopia. Si un bug est découvert, il est alors extrêment facile de le reporter puisque Testopia est ancré dans Bugzilla, ce qui vous permet ensuite de dire “le test foo_bar a échoué à cause du bug 12345″ et un lien pointe directement vers le bug en question afin de facilement suivre la progression concernant sa résolution (ça va, vous me suivez toujours?). Une barre de progression tenant compte de tous les bugs de la liste vous permet de savoir à tout instant où en est la phase de tests. Bien entendu, vous pouvez avoir autant de listes de tests que vous le désirez (par exemple “liste pour version alpha”, “liste pour version beta”, liste pour RC”, “liste pour version finale”). Le détail des fonctionnalités se trouve sur le site mentionné plus haut (en anglais).

__

Testopia 1.3, compatible with Bugzilla 3.0, has been released! This version supports PostgreSQL as well as mod_perl (unlike version 1.2 and older) .

Testopia is a program which lets you easily manage testcases and is applied directly on the Bugzilla code (thanks to a patch provided in the tarball). Said otherwise, Testopia lets you define a list of tests to run before releasing a product and then store the results of these tests. If a bug is discovered while running some given test, you can then easily file a bug to report the problem as Testopia is directly integrated with Bugzilla. This way, you can easily link the test which failed with the corresponding bug in Bugzilla and keep track of it. A progress bar lets you have an overview of how tests are going. Of course, you can have more than one list at the same time, e.g. “tests for alpha versions”, “tests for beta versions”, “tests for release candidates”, etc…. More details about Testopia are available on the website linked above.

Je viens juste de demander sur IRC dans #firefox comment un administrateur peut partager une extension avec tous les utilisateurs; en d’autres termes, rendre l’extension globale. J’ai suggéré d’avoir une case à cocher, comme dans OpenOffice lorsqu’un administrateur installe un dictionnaire, ce qui est franchement très utile. Et la réponse franchement débile que j’ai reçue est qu’un administrateur ne représente que 0.01% des utilisateurs, et que de toute façon un administrateur sait comment utiliser des lignes de commandes pour faire cela, ou alors qu’il peut utiliser CCK. Grandiose! Donc non seulement vous devez être licencié ès Informatique pour faire une action semble-t-il aussi simple, mais en plus il vous faut apprendre chaque truc et astuce pour chaque logiciel que vous souhaiteriez utiliser ou tout simplement pour gérer votre installation.

Je veux juste dire une chose: tous les administrateurs ne sont pas des “pros” de l’informatique. Un bel exemple est l’enseignant à qui l’on demande de s’occuper du parc informatique de l’école dans laquelle il travaille, de maintenir les programmes à jour et de maintenir le système fonctionnel. Ce genre de tâches n’est pas exactement le point fort premier d’un enseignant. Et ce n’est qu’un exemple parmi d’autres (imaginez n’importe quelle autre “petite” entreprise qui essaie de se débrouiller seule). Et même à la maison, lorsque vous essayez de partager une extension avec votre femme et vos enfants parce que vous jugez qu’elle peut être utile, là aussi vous ne souhaitez pas passer par la ligne de commande que de toute façon vous ne connaissez pas, malgré que votre système d’exploitation dit que vous êtes “l’administrateur” de votre système.

Cela veut-il dire que Firefox est conçu pour les mordus de l’informatique seulement?

–

I just asked in #firefox on IRC how an admin can share an extension with all users (a.k.a. globally). I suggested why not having a checkbox on installation which you can mark if you want the extension to be available to all users? This is what you see when an admin installs a new dictionary with OpenOffice 2, and this is really helpful! A reply I got was of the form “admins are only 0.01% of users, and admins know how to use command lines to do it, and there is CCK too”. Great! I have never heard of something more ridiculous than that. So not only must all admins have a PhD in Computer Science to use Firefox in an optimal way, but they must also learn all the tricks from all the software to manage their network.

I just want to say one thing: not all admins are developers/hackers nor do they have time to search in the documentation which command line (if any) to type. One precise example I have in mind is teachers who have been asked to manage the network of the school they are working in, and to keep softwares up-to-date and to have everything working correctly despite administering a network for some hundreds of users is not their exact primary skill. Even you at home, when you install an extension and want to make it available for your wife and children, because it’s exactly what your family needed, is not necessarily an “expert”, even if your settings say you are an admin.

So is Firefox for advanced users only?

Facile, il suffit de travailler sur le projet Bugzilla. Après avoir écrit un patch, vous avez amplement le temps de vous consacrer à vos autres activités avant de connaître sa destinée (review+ ou review-). Ca a beau faire bientôt 3 ans que je travaille sur ce projet, les longues attentes durant lesquelles vous avez l’impression que le projet hiberne m’irritent toujours autant.

Peut-être devrais-je trouver un projet alternatif sur lequel travailler pour combler ces longues attentes, si possible écrit en Perl pour rester dans un langage familier. Des suggestions?