In my previous post, I talked about the new front page which will be used in Bugzilla 3.4 (it will very likely change again in Bugzilla 3.6 to look something like this). Now I’m going to talk about the new form to file bugs. Technically, it’s the same page as before, but we now hide some fields by default which we don’t consider to be critical when reporting a new bug.

The form to file bugs in Bugzilla 3.2 and older looks like this:

Full bug filing form

There are many fields which advanced users probably love to see when reporting a new bug, but they may look too complicated for newbies. With the idea that newbies know mostly nothing about the internals of Bugzilla, and that they probably won’t know what to set, we know display important fields only, by default:

Simple bug filing form

The information requested here seems small enough to not frighten new reporters. We could even imagine hidding the OS + hardware fields, as well as the component field, but I suppose the form would then look a bit too much like Hendrix. Anyway, it’s still a big improvement over what Bugzilla 3.2 displays to the user. And before you ask: yes, you can display all fields if you want to. Simply click the “Show Advanced Fields” link at the top of the page. Bugzilla will store your choice in a cookie so that you don’t have to worry about it in the future. Cool, isn’t it?

In my next post, I will show you how administrators can configure Bugzilla 3.4 to display some fields under certain circumstances only (for instance, on a per-product basis, or only for a given severity/priority, etc…) Another cool feature.

This is the first post about new features/UI improvements available in what will become Bugzilla 3.4. I realized that many readers don’t waste their time following links in articles; if a screenshot is not included in the article itself, they ignore links pointing to them. So I decided to insert as many screenshots as possible so that you have them immediately in front of you. And also, you can no longer complain that you didn’t know about such or such (bad) improvements when your Bugzilla installation is upgraded.

Today, I will talk about what will be the most noticeable UI change: the front page.

Front page displayed to logged out users

Above can you see the new front page displayed to logged out users. There are two major changes: the 3 big buttons in the center of the page, and the login form in the header and footer of the page (the login form is now in the header and footer of all pages). The first button (the green one) will let you file a new bug. Of course, it will display the login form first as you cannot file anonymous bug reports. The second button (the orange one) will display the search page (the specific or advanced search based on your cookie; the specific one being the default). And the third button (the blue one) will let you create a new user account. Below buttons can you see a search field, well known as a “quick search” (which is more powerful than the specific search form, which is mostly useless, but less powerful than the advanced search form. My vote to kill the specific search form completely, but that’s another story).

Some users already complained that there are now 6 ways to run searches from this single page: the “Search” link in the header, the “QuickSearch” form in the header (the one with the “Find” button) the big orange button in the middle, the “QuickSeach” form below big buttons, the “Search” link in the footer and the “QuickSearch” form in the footer (again, the one with the “Find” button). I agree this may look confusing to new users. Also, there are now 3 links to create a new user account: the “New Account” link in the header and in the footer as well as the big blue button. And finally, some complained that the “File a Bug” button is useless as you have to log in first anyway. Not ideal? Your feedback is welcome!

When you are logged in, the front page will look like this:

Front page displayed to logged in users

The only major difference compared to the logged out page is that the blue button now points to your user preferences. Also, the login form disappeared and is replaced by your login name, as in previous Bugzilla versions. We all agree that this page is suboptimal for logged in users, as much more useful data could be displayed instead of these big buttons (advanced users already use links in the header/footer of the page anyway). But we plan to improve it for Bugzilla 3.6.

Do you like it? Do you hate it? You have no opinion? Please let us know!

We finally released Bugzilla 3.2.3 and Bugzilla 3.3.4 last night, March 30. All existing Bugzilla 3.x installations will get automatic notifications within 24 hours (if administrators enabled this feature).

Bugzilla 3.2.3 fixes some important bugs:

• One of the security fixes implemented in Bugzilla 3.2.1 broke the ability to edit several bugs at once if the installation was using a shadow DB with the –read-only option (Bugzilla was trying to write into the shadow DB instead of the master DB). Installations not using a shadow DB are not affected by this issue.
• Due to our new token protection implemented in Bugzilla 3.2.1 to prevent unwanted bug changes, some Bugzilla clients were unable to edit bugs anymore as they had no valid token in hands. The XML format of bugs now contains a valid token which can be used to edit them (keep in mind that the token is generated based on the user ID, so you cannot use your own token with someone else, which is the goal of using tokens!).
• Saved searches with UT8 characters in their name no longer crash Bugzilla (again a regression due to one of the security fixes implemented in Bugzilla 3.2.1).
• Due to a change in MySQL 5.1.31 and newer, “SET SESSION max_allowed_packet” is no longer allowed, making previous versions of Bugzilla 3.2.x to fail. This problem is now fixed.
• Attachments now have the same token protection as bugs themselves. This is our last security fix related to cross-site request forgery (read the previous security advisory if you want to see which other areas were fixed in our previous security release).

All known regressions introduced in Bugzilla 3.2.1/3.2.2 have been fixed in Bugzilla 3.2.3. This means you really should upgrade your installation to 3.2.3.

Bugzilla 3.3.4 is our last development release before Bugzilla 3.4rc1. This means it’s feature complete and we will now only focus on bug fixes (enhancements are no longer allowed on this branch). Newly introduced features are listed in the Status Update. The most significant change is the new front page (screenshot). Feedback is much welcome! Please keep in mind that Bugzilla 3.3.4 got no QA at all, meaning that it’s potentially unstable. If you need a stable release, use Bugzilla 3.2.3.

To developers, note that we have reopened the trunk and new enhancements are again allowed. The current trunk version is Bugzilla 3.5 (which will become Bugzilla 3.6 when it’s stable). The 3.4 branch is tagged BUGZILLA-3_4-BRANCH.

As described in bug 480001, MySQL 5.1.31 and newer no longer let you write ‘SET SESSION max_allowed_packet = xxxx’ (this variable is now read-only, unless set globally). As we are calling it from two different places in Bugzilla 3.2, 3.2.1 and 3.2.2, those versions won’t work together. I hope this problem will be fixed in Bugzilla 3.2.3.

Update: this bug has been fixed and will be available in Bugzilla 3.2.3, which should be released very soon now (probably next week).

On February 2, around 17:40 PST (Feb 3, 1:40 GMT), we happily released Bugzilla 3.3.2, 3.2.1, 3.0.7 and 2.22.7, which fixed several security issues. Less than 3 hours later, bug 476594 was filed on b.m.o, reporting a problem with srand() on mod_perl (read details in the bug), which is called when you call rand() in your code. This bug was undetected while writing security patches and while reviewing them, because most developers don’t use mod_perl on their test installations. Also, this problem hasn’t been detected on our “secret” mod_perl test installation, probably because race conditions couldn’t occur due to the low number of testers playing with it at the same time. But as soon as b.m.o upgraded to Bugzilla 3.2.1, the problem became very clear, and we have to address a big THANK YOU to Philippe M. “gozer” Chiasson to help us debug and fix the problem very quickly. Only 9 hours after the releases mentioned above, i.e. on February 3 around 2:40 PST (Feb 3, 10:40 GMT), Max Kanat-Alexander, our release manager, uploaded new tarballs on the FTP server, and the website was updated to announce the immediate release of Bugzilla 3.3.3, 3.2.2 and 3.0.8, with this single change in them (it’s actually a single line change). We didn’t release Bugzilla 2.22.8 as 2.22 doesn’t support mod_perl, and so is not affected by the problem.

That was a pretty intense and busy evening/night/morning (depends where you live on the planet) for Bugzilla developers: first, we had to commit 20 security patches (backports included) to CVS, then fix some QA scripts which were affected by the security fixes above, create and upload tarballs, update the website, then track the problem with srand() on mod_perl, review the patch, write and review the new security advisory and new release notes (it was the first time I had to do reviews from work…. you know, I’m teaching ), recreate and upload tarballs again, and finally update the website once more. Wow! But things seem to be going well now; no regression has been reported to b.m.o (yet).

As announced last Saturday, we released Bugzilla 3.3.2, 3.2.1, 3.0.7 and 2.22.7 today! Read the Security Advisory and the Status Update for more information. If you want to keep informed about the Bugzilla activity, you should know that there is now a “Bugzilla Community” group on Facebook. Feel free to join!

Max is a bit more verbose than me today. You can read his article here.

A quick note to let you know that Bugzilla 3.3.2, 3.2.1, 3.0.7 and 2.22.7 should be released on Monday (in two days). All security patches have been reviewed, all blockers have been fixed, and release notes are also ready. Those are important security releases, do no miss them!

–

Un mot rapide pour vous dire que Bugzilla 3.3.2, 3.2.1, 3.0.7 et 2.22.7 devraient sortir lundi dans 2 jours. Tous les patchs de sécurité ont été approuvés, tous les bugs bloquant la sortie ont été résolus, et les notes de mise à jour sont prêtes. Il s’agit de mises à jour de sécurité importantes, alors ne les manquez pas!

Bugzilla 3.3.1 has been released last night and is the first development snapshot of what will become Bugzilla 3.4, whose feature freeze date is January 29, 2009. More important new features are available in the last Status Update: users can choose their timezone to display dates and times (especially in bug comments), several improvements to custom fields, two new WebService functions (Bug.get_history and User.get), there is now an email preference to get bugmail for new bugs, users can re-order columns in buglists, user account passwords are now encrypted using SHA-256 instead of the UNIX crypt() function (passwords longer than 8 characters are now correctly validated!), some parameters considered obsolete have been removed, Bugzilla can now use an asynchronous job queue for sending mail (optional and disabled by default, check your parameters), on midair collisions users can decide to only submit the comment and skip other changes, … and of course code cleanup and improvements (such as decreasing the load on the DB when viewing bugs, refactoring of the product and classification code).

In a couple of days (I hope!) will also be released Bugzilla 3.3.2, 3.2.1, 3.0.7 and 2.22.7 with several security fixes (a last one to fix, and we are ready to go). Stay tuned!

Bugzilla 3.2rc2 est enfin disponible depuis hier (la date officielle de sortie est le jeudi 6 novembre, mais avec le décalage horaire, il était déjà vendredi matin en Europe). Cette version, largement basée sur les retours que nous avons reçus sur la version 3.2rc1, sera la dernière RC avant la sortie de la version 3.2 finale. Celle-ci devrait être disponible avant la fin de l’année (voire même d’ici à la fin de ce mois, pour les plus optimistes).

Pour ceux qui auraient déjà installé la version 3.2rc1, voici les principaux changements entre ces deux versions:

• La mise à jour d’une version antérieure de Bugzilla vers la version 3.2rc2 devrait être beaucoup plus rapide avec MySQL par rapport à une mise à jour vers la version 3.2rc1. La partie du code convertissant la table utilisant des indexes “fulltext” était particulièrement lente. Celle-ci est maintenant environ 10 fois plus rapide sur de très grandes installations.
• Si SSL est activé pour les utilisateurs identifiés (ssl=’authenticated sessions’), toutes les pages sont désormais sécurisées, et pas seulement les pages où les utilisateurs s’identifient. Auparavant, un utilisateur pouvait accéder à une page utilisant http:// sans que Bugzilla ne réagisse. Dorénavant, Bugzilla redirige l’utilisateur vers https:// dans tous les cas. Pour les modes ssl=’always’ et ssl=’never’, il n’y a pas de changement.
• Les cookies d’identification ne sont désormais plus accessibles aux scripts JavaScript, grâce à l’attribut HTTPonly. Ceci dans le but de renforcer la sécurité. De même, si SSL est activé, alors ces cookies ne peuvent être transmis que sur des connexions sécurisées, grâce à l’attribut ‘Secure’. Cela veut dire qu’en accédant à Bugzilla via une adresse http://, les cookies d’identification ne sont pas transmis, ceux-ci n’acceptant que des connexions sécurisées https://.
• Bugzilla devrait être globalement plus rapide, grâce à l’optimisation de certaines requêtes, ce qui diminue notablement la charge sur le serveur SQL. De plus, les pages de style CSS sont chargées avant les scripts JavaScript, ce qui permet au navigateur de déjà commencer à afficher les page pendant le chargement des scripts (notamment en utilisant Firefox).
• Plusieurs améliorations concernant l’interface utilisateur (UI) lors du visionnement des bugs. Nous espérons avoir enfin trouvé une mise en page qui convienne au plus grand nombre, sans entraver leurs tâches quotidiennes.
• Le “keyword chooser” (sélecteur de mots clés) a été retiré de la version 3.2rc2. Beaucoup de retours ont été très négatifs concernant cette fonctionnalité. Celle-ci interférait avec les raccourcis claviers dans certains navigateurs et ne permettait plus de rentrer manuellement les mots clés dans les bugs, ce qui était perçu comme une régression inacceptable. Nous espérons proposer une variante plus appropriée dans la version 3.4.
• Si Bugzilla nécessite une mise à jour de son serveur SQL ou si celui-ci est inaccessible pour une quelconque raison, le paramètre ’shutdownhtml’ fonctionnera quand même. Dans les versions 3.2rc1 et antérieures, un message d’erreur (Software Error: …) était affiché comme quoi le serveur SQL était inaccessible, ce qui n’était guère utile pour les utilisateurs.
• Dans la version 3.2rc1, Firefox ne parvenait plus à mettre les pages visitées en cache, ce qui ralentissait notablement la navigation. Ce problème est désormais résolu.
• Le support d’Oracle comme serveur SQL a été grandement amélioré.

En plus de la version 3.2rc2, nous avons également sorti les versions 3.0.6, 2.22.6 et 2.20.7 fixant un problème de sécurité concernant les “quips”, ces petits messages apparaissant en haut des listes de bugs. Il est vivement conseillé de mettre à jour votre installation pour vous prévenir de cette faille.

On planet.m.o, I see tons of tinyurl’s used to point to lists of bugs (a.k.a buglists). When you run a complex query, this is indeed the best solution for now (till bug 400063 is fixed), but in many cases, the query is simple enough to avoid tinyurl. How? Use QuickSearch!

For those who don’t know, QuickSearch is a built-in feature of Bugzilla. This is the small textbox on the left of the “Find” button you can see on all Bugzilla pages, in the header and in the footer. Maybe you think that all it can do is to get a bug ID and go to this bug when you click the “Find” button, but it can do much more than that!

Let’s take a few examples from recent posts on planet.m.o:

Example 1: Alex Faaborg’s post about polish bugs:

The “Hard Polish Bugs” link currently points to http://tinyurl.com/5e9dd7 but could be replaced by https://bugzilla.mozilla.org/buglist.cgi?quicksearch=prod%3ACore%2CFirefox%2CToolkit+sw%3A%22[polish-hard]%22+kw%3A%22polish%22 (click here for a try). How to get it? In the textbox mentioned aboved (or if you installed the Bugzilla Quick Search plugin, you can get the same result from here), you type:

prod:Core,Firefox,Toolkit sw:"[polish-hard]" kw:polish

“prod:” means “product”, “sw:” means “status whiteboard” and “kw:” means “keywords”. As you are querying in more than one product, you enumerate them separated by a comma. About the status whiteboard, I wrote [polish-hard] between quotes, but they are not mandatory in this case as there is no whitespace nor comma. But I’m used to add them by default for this field as most of the time I’m looking for something of the form [foo bar], i.e. with whitespaces. Without quotes, Bugzilla would read sw:[foo only and wouldn't know what to do with bar] (well, it knows what to do with it, but that’s not what you expect in this case).

You immediately see how to easily build the link for “Easy Polish Bugs“. All you have to do is to type:

prod:Core,Firefox,Toolkit sw:"[polish-easy]" kw:polish

and you get this URL.

Example 2: Mozilla Platform meeting minutes: 2008-10-28:

The “JS 1.9.1 Bugs” link about wanted bugs for JavaScript could easily be obtained by:

prod:Core comp:"JavaScript Engine" flag:wanted1.9.1+

which generates this URL. Here, “prod:” is again the product, “comp:” means “component”, and “flag” is… a flag. In this example, quotes are mandatory for the component because its name has a whitespace in it. Note that you don’t need to specify that you only want open bugs; that’s the default!

Example 3: Calendar Community Testday On Thursday, October 30:

The “some fixed tb-integration bugs that need to be verified” link could be obtained by:

RESO prod:Calendar resolution:FIXED flag:integration

which would generate this URL. Note that we start to type RESO, which means you want bugs with the RESOLVED bug status only. As I said above, the default is to only look for open bugs. If you don’t want to use this default behavior, you have to mention this as the first argument. Then, “resolution” is the bug resolution, here bugs marked as FIXED only. And finally, “flag:” contains a flag name with no +/-/?, meaning that you don’t care, you want all of them. Also, “integration” is not the complete flag name, it’s “tb-integration”. So Bugzilla would return all bugs matching the above criteria, and would also catch bugs having e.g. “fx-integration” if it exists.

Last trick of the day:

If you want to see all bugs waiting for your (super-)review, you can easily get them all at once typing e.g.:

flag:review?LpSolit

Just replace my nick on b.m.o by yours, of course. A shorter alternative is:

review?LpSolit

Bugzilla will automagically consider this last case as a flag due to “?” being detected in the string. That’s the only case where “flag:” is optional. If you suspect there may be requests for review in bugs which are already resolved (either RESOLVED or VERIFIED), you can ask for all of them thanks to:

ALL review?LpSolit

ALL is specified as the first argument to override the default and will make Bugzilla look for both open and closed bugs.

Note that you cannot do everything with QuickSearch. For instance, those testcases are not possible for now.

As I see more and more people asking when Bugzilla 3.2 final will be available for download, I decided to blog about it here: We will first release Bugzilla 3.2 RC2! This hard decision has been taken during our last Bugzilla meeting last week. The reason is that we did many checkins since RC1 and we may have potentially regressed something. But for all those who are impatient, you must know that Bugzilla 3.2 RC2 should be stable enough for production, and is currently in use by both Mozilla and RedHat, just to name a few. But be aware that QA is not complete yet, so there may be hidden (severe) regressions somewhere (even if I don’t think that’s the case; but who knows?).

I’m publishing this article on behalf of Guy Pyrzak, our UI guy at Bugzilla:

With the recent upgrade of BMO to 3.2, there have been a few usability improvements and a few regressions. These are all things that might be expected with major upgrades to any UI. The Bugzilla team has enjoyed getting the feedback from Mozilla users about how to further improve the User Interface. We’re really trying to focus on improving Bugzilla’s User Interface in the coming versions, but part of doing that is getting good user data. We’ve even got a student group at Carnegie Mellon to do several user studies on how people use bug trackers and Bugzilla in their every day work. However, in order to do user studies they need to find Users!

This is where you all come in. We need some volunteers, in the Pittsburgh PA area to allow our student group to come into wherever you use Bugzilla, home, work etc and video tape, and interview you you while you do your work. The students will have an IRB waiver for you to sign, which just makes sure you’re not harmed while they watch you. The students will want to understand how and why you do your job. They’ll ask you some questions about how you do your work, and why you do, whatever it is you do. In the HCI community this is called a Contextual Inquiry. To find out more about how a Contextual Inquiry works you can read more on Wikipedia.
If you’re not able to let a student group come to your work, but still live in the Pittsburgh PA, you can still help us out! The students will also conduct studies in a more controlled environment, that isn’t where you work. So if you can’t let the student group visit your workplace, please still contact us. The more users we’re able to observe the more data we can collect, and the more we can improve Bugzilla!

Not to worry, we’re also doing other types of usability studies and analysis, but this was an instance where you all could help. Contact guy.pyrzak@gmail.com, or just comment on this blog if you’re interested.

While talking on IRC about how to make editable fields and the comment box closer so that you can easily comment and edit fields, especially the bug status, I suggested this mockup (ignore the fields you never heard about in the right column, those are custom fields). Is that something you would like to see officially implemented in Bugzilla? Or do you think it’s not better than what we have currently, i.e. the comment box just below the attachment table?

As most of you know, Bugzilla 3.2rc1 is available for download since August 12 and bugzilla.mozilla.org upgraded to this version two weeks later, last Thursday. As I wrote in my last blog, b.m.o is not the first major installation to upgrade to 3.2rc1, so now seems a good time to get some feedback from people using this version of Bugzilla to know what’s their feeling with it, both about its UI and about its usability and new features. Mozilla folk reported a pretty large number of bugs, usability regressions, and complains, but as someone told me, they didn’t file bugs for things they like. So I thought this blog would be a better place to get your feedback, both positive and (highly?) negative, to get a better picture of what people think before releasing the final version of Bugzilla 3.2.

Note that this feedback can come from everybody using Bugzilla 3.2rc1 (or 3.1.4+), such as users of RedHat’s Bugzilla or OpenSSH’s Bugzilla, or even from smaller installations which already upgraded to this version. The wider the audience, the better.

As discussed at our last Bugzilla meeting last week, we plan to release Bugzilla 3.2 very soon now. We currently don’t plan to release a second release candidate as no (critical) bug has been reported about 3.2 RC1 yet. During this time, Bugzilla 3.0.x remains our most recent stable branch and more and more people are using it. Stats show that Bugzilla 3.0.4, released on May 4 this year, has already been downloaded 120,500 times (which means 1200 downloads per day)! Not bad at all!

When I saw that, I was interested to know if major Bugzilla installations upgraded to Bugzilla 3.x already or not. Results show that it’s the case for many of them:

• OpenSSH: 3.2rc1+
• PRACA (NASA): 3.2rc1
• RedHat: 3.1.4+ (mostly 3.2rc1 as they upgraded 2 weeks before this release)
• KDE: 3.0.5+ (which is 3.0.5 as there is no code change)
• Mandriva: 3.0.5
• Mozilla: 3.0.4+ (bug 450310)
• Apache: 3.0.4
• Facebook: 3.0.4
• W3C: 3.0.4
• Eclipse: 3.0.4
• Songbird: 3.0.4
• Wine: 3.0.4
• ActiveState: 3.0.3
• FreeDesktop: 3.0.3
• Itos (NASA): 3.0.2
• Novell: 3.0
• WikiMedia: 3.0
• ClamAV: 2.22.3
• Kernel.org: 2.22.2
• Maemo: 2.22.1
• Yahoo: 2.22.x (thanks Max for the info!)
• Gentoo: 2.22 (bug 213782)
• Gnome: 2.20.5 (bug 433607)
• WebKit: 2.20.1 (bug 17457)
• GCC: 2.20+
• Samba: 2.20

• OpenOffice: no comment (2.11, very ugly)

Interesting snapshot.

After a very long delay, Bugzilla 3.2 RC1 is finally out! We also released Bugzilla 3.0.5 and Bugzilla 2.22.5 to address a minor security bug.

Bugzilla 3.2 RC1 has many new features compared to Bugzilla 3.0, among which a new default skin (the old one is still available from your user preferences) and major changes to the “Bug Editing” (a.k.a show_bug.cgi) page. You can now also customize bug statuses (including adding new bug statuses) as well as the workflow to go from one bug status to another one. You can also decide which bug statuses are available when filing a new bug (in Bugzilla 4.0, we even plan to let you file bugs as RESOLVED directly!). Just in case you forgot, you can already customize the list of resolutions since Bugzilla 3.0. Bugzilla 3.2 RC1 also supports three new custom field types (besides the two already available in 3.0): multi-select fields, multi-line textboxes and date/time fields (with an integrated JS calendar popup to select dates more easily).

In the backend, Bugzilla 3.2 RC1 now supports Oracle as its database (it already supports MySQL and PostgreSQL for a very long time). Note that this support is still experimental, and there are still a few known bugs when using Oracle, so be careful if you use this database. In the l10n area, Bugzilla now fully supports UTF-8 and should work with most (if not all) languages around the world. Also, you can now install localized templates much more easily, including translated documentation which can now be installed without conflicting with other languages (previously, the documentation was in docs/html/, so each l10n doc would overwrite previously installed doc. Now they are located in docs/%lang%/html, so that you can have docs/en/html, docs/fr/html, docs/de/html without any conflict). When you click the new “Help” link at the top of each page, a new tab/window is opened with the documentation related to the page you are viewing in the language reported by your web browser (if this l10n doc package is installed server-side, of course)!

There is much more to say about new features. I could talk about the new Administration page (instead of all these administration links in the page footer, which have all been removed), about the new JS widget which lets you select keywords when editing bugs much more easily (no need to remember how a keyword is named, just select it from the list to have it added or removed), about SMTP authentication support, about DB transactions (instead of locking tables to read/write in them, and which also allows us to roll-back changes if something goes wrong in the middle of an update), about improvements to the extensions system (previously known as the plugin system), or about the ability for administrators to specify the port to use when enabling SSL to access their Bugzilla installation. But I prefer to let you read the list of new features yourself.

I hope you will enjoy using Bugzilla 3.2 RC1, and if you find any bug or have a great idea to improve it even more, please file a bug! Contributions (patches, QA, doc writing) are also welcome!

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.