Archive

Archive for avril 2012

Bugzilla 4.3.1, 4.2.1, 4.0.6 and 3.6.9 released

We released Bugzilla 4.3.1, 4.2.1, 4.0.6 and 3.6.9 a few hours ago, and they all contain 2 security fixes. All installations are highly encouraged to upgrade to these new releases. Bugzilla 3.6.9 and 4.0.6 only contain the two security fixes mentioned in the security advisory. Bugzilla 4.2.1 also contains a pretty large list of bug fixes, which makes it a good candidate to upgrade to the 4.2.x series if you didn’t upgrade to 4.2 yet. Note that Bugzilla 4.2.1 is also the first release to work with Testopia without needing to be patched first. A new release of Testopia should be available soon, which will take advantage of the improvements and new hooks available in 4.2.1.

We also released Bugzilla 4.3.1 which is the first development snapshot of the 4.4 series. I’m going to list some of the new features and improvements available:

  • A new user preference lets you decide if you should be CC’ed when someone requests something from you via a flag. For instance, requesting someone for review would automatically CC the reviewer to the bug.
  • Unset flags are now hidden by default, in bug reports.
  • Duplicates are now listed at the top of the bug report, close to the dependency lists.
  • URLs pointing to GitHub (github.com) are now accepted in the See Also field in bug reports.
  • Personal tags can now be displayed in buglists. In Bugzilla 4.3.2, you will also be able to tag bugs from the bug reports themselves. This means the ugly box at the very bottom of every page will go away.
  • You can now hide the description displayed at the top of buglists containing all the arguments passed to the query.
  • You can now use pronouns (%reporter%, %user%, etc.) with the flag setter and requestee fields in boolean charts.
  • A new email preference has been added to get emails when the product or the component of a bug changes.
  • Bugzilla now keeps track of the last time a user used his account to access Bugzilla. This will let admins know which accounts are inactive.
  • Bugzilla now supports SSL connections to SMTP servers.
  • Target milestones can now be 64 characters long (instead of 20) to match the same limit as versions.
  • Whine emails now correctly take the sort order of buglists into account.
  • Several new WebServices methods: User.update, Product.update, Group.update, Bug.update_tags, Bugzilla.parameters (read-only), Bugzilla.last_audit_time.
  • Several existing WebServices methods have been improved to return more data.
  • The documentation is now generated using xmlto instead of jade.
  • Several performance improvements have been made when viewing large bug reports.
  • The Bugzilla source code now uses the MPL2.0 license, instead of the MPL1.1 one.

We are one month away from the freezing date for new features in Bugzilla 4.4. So if some of you really want something for 4.4, you have exactly one month left to submit patches, or find a kind developer to write the patch for you. Also note that Bugzilla 4.4 will be the last release to support Perl 5.8.x. The next major release, Bugzilla 4.6, will require Perl 5.10.1 or better.

Catégories:Bugzilla, Mozilla

Testopia 2.5 will work with Bugzilla 4.2.1 pretty decently

You probably noticed that there has been no activity related to the development of Testopia, a Bugzilla extension, for more than a year. The reason is that its maintainer, who was the single contributor to this project, had a new job and has no time to work on it anymore. Consequently, the latest version of this extension, Testopia 2.4, which was released in October 2010 (!), only works with Bugzilla 3.6, but not 4.x.

You will be happy to hear that with the help of some new contributors wanting to make Testopia work with Bugzilla 4.2, I committed several patches to the bzr repository which make it work pretty decently with Bugzilla 4.2.1 (probably also with Bugzilla 4.0.x, but I didn’t test). There is no official release yet (it should be named Testopia 2.5), but you can download updated files using bzr. Make sure to revert changes made to the core code of Bugzilla first before applying the new code.

To make things clear: I’m not the new maintainer of this extension, and I have no plan to take this role. I’m busy enough with my roles as assistant project lead + reviewer + QA lead + bug triager + developer for the Bugzilla project. I simply decided to help the new contributors who jumped in these last few days and used my commit access to the Testopia repository to commit some patches. The Testopia maintainer is still alive, and emailed me this morning. So he is still the one who will take the decision to release 2.5 when it’s ready. :)

Update: Starting with Bugzilla 4.2.1, you no longer need to patch the source code of Bugzilla to make it work with Testopia 2.5! If you are upgrading from Testopia 2.4 or older, make sure to revert the changes made to the source code first.

Catégories:Bugzilla, Mozilla
Suivre

Recevez les nouvelles publications par mail.