Bugzilla 5.0 moved to Python (bye bye Perl!)

This discussion took place three years ago, and we have been working very hard to make it happen. But we are now done: Bugzilla 5.0, the next major release of Bugzilla which will be released later this month on April 31, will be based on Python 3.4, meaning that Bugzilla 4.4 was the last major release to be based on Perl. We hope this migration to Python will trigger more contributors and will increase the development rate of Bugzilla.

Bugzilla 5.0 comes with many major changes. Just to name a few:

  • Support for Internet Explorer (including IE 11) and less known browsers has been removed. You must now run Firefox, Google Chrome or Safari, which fully support HTML5, else an error message will be displayed asking you to use one of these browsers.
  • You must have Java 8 installed and enabled in your browser in order to upload new attachments. This way, sanity checks can be done client-side before the attachment is uploaded to Bugzilla. If you don’t have Java installed or enabled, you can still view existing attachments, though, but you won’t be able to upload new ones.
  • The version 5.0 of Bugzilla can be downloaded for free, but security fixes (5.0.1, 5.0.2, …) require that you register to our server to be able to download them. The fee isn’t expensive: $20 per security release for installations with less than 10 users. $200 between 10 and 50 users. $1000 above 50 users. As we do security releases only once every 4 months or so, this means that you can keep your installation safe for only $60 per year (or $3000 for larger installations).
  • For other changes, please read the Bugzilla 5.0 release notes.

Enjoy!

Note: For the ones who didn’t notice when I wrote this post (April 1): yes, it was an April fool!

Catégories:Bugzilla, Mozilla

Bugzilla 5.0 moved to HTML5

A quick note to let you know that starting with Bugzilla 4.5.2, which should be released soon (a few weeks at most), it now uses the HTML5 doctype instead of the HTML 4.01 Transitional one. This means that cool new features from HTML5 can now be implemented in the coming Bugzilla 5.0. A lot of cleanup has been required to remove all obsolete HTML elements and attributes, and to move all hardcoded styles into CSS files, and to replace many <table> by <div> where appropriate. There are still many places to fix to be fully HTML5 compliant as HTML 4.01 was more lenient with some code, but we did a great jump toward the HTML5 world.

Catégories:Bugzilla, Mozilla

Want to fix a bug before it exists? Enter the TARDIS

doctor_who

 

Catégories:Bugzilla

Bugzilla 15th anniversary

This week, Bugzilla turns 15! On September 18, 1998, Terry Weissman released Bugzilla 2.0, the first version written in Perl. A few days before, on August 25, 1998, the Bugzilla source code was committed to CVS for the first time, and was written in Tcl (Terry decided to rewrite it in Perl to attract more contributors). Since this first public release, Bugzilla changed a lot, though some of its original features are still clearly recognizable. You may wonder how Bugzilla looked like 15 years ago? Well, I’m going to tell you all.

Installing Bugzilla 2.0 wasn’t as easy as it is today. You had to manually run six(!) scripts to create DB tables and to populate them (checksetup.pl only replaced them in Bugzilla 2.8). The tarball was very small, only 52 KB (compared to 2.4 MB for Bugzilla 4.4), and you needed MySQL 3, Perl 5.4 and a web server. The home page was pretty…. simple:

index13

So what do we see? A link to the search page, another link to file a new bug, and a text box to enter the ID of an existing bug. Oh, and a huge picture of an ant. You can see that there is no link to create a new account. That’s because there is no UI for that! To create an account, you had to click on "Enter a new bug", and Bugzilla would ask your credentials. As you have none, you had to click the "Forgot password" button, and Bugzilla would send you an email with your password in it. This had the side-effect to automatically create an account for you with the email address you just gave and the password included in the email you just received. This page has evolved a lot, and it now looks like this in Bugzilla 4.4:

index44

Big icons help users to more easily find what they are looking for, and the page header and footer also make navigation through pages much easier.

Once you pass this first page, the next step is the search page:

query13

Yes, the page says "Bugzilla 1.2", but it’s really 2.0 minus one minor string change in the parameters page (1.2 is only 70 minutes older than 2.0). As you can see, the search page is not very different from what we have today:

query44

The product, component, bug status, resolution, severity and priority fields are still here. The main difference is that we greatly improved search capabilities of Bugzilla, and all the sections above are expandable to offer more search criteria:

query44_2 query44_3

And many new bug fields appeared, such as the target milestone, keywords, the status whiteboard, attachments and flags.

The buglist didn’t change a lot either:

buglist13

Note that I had to fix the code to correctly display <table> in the bug summary. Bug summaries weren’t HTML-escaped, and so it was trivial to inject arbitrary code in the buglist. But this shouldn’t be a surprise to anyone as we had to wait 8 years for Bugzilla 2.18 to see correct HTML-escaping. :)

To file a bug, you had to first select the product…

enter_bug13

… and then enter details of the bug report:

enter_bug13_2

If these pages look familiar to you, that’s because they didn’t change a lot in the last 15 years:

enter_bug44

The main difference is that the product description has been added to help users select the right product.

enter_bug44_2

This is the simple form to report new bugs. If you click the "Show advanced fields" link, more fields are displayed. You now also have the possibility to attach a file and to set flags when reporting a new bug. Attachments and flags didn’t exist in Bugzilla 2.0. Attachments have been implemented in 1999 in Bugzilla 2.4, and flags in 2002 in Bugzilla 2.18. And you had to wait for 2006 and Bugzilla 3.0 to be able to attach files and set flags on bug creation.

Bug reports in Bugzilla 2.0 had very few fields and, of course, were not customizable:

show_bug13

You probably recognize knobs which have been removed in 2008 in Bugzilla 3.2 in favor of a better UI. Also, you will note that comments were all concatenated into a single comment, making it impossible to track who commented in the bug, and when.

On the backend, things have changed a lot. First of all, the number of DB tables exploded. In Bugzilla 2.0, there were only 7 tables:

db_schema13

In Bugzilla 4.4, there are more than 70 tables (the output is truncated):

db_schema44

The exact number of tables will depend on the number of custom fields. The reason for so many tables is because Bugzilla now has many new features which didn’t exist in previous releases, and admins now have the ability to edit mostly everything to customize Bugzilla as desired. In Bugzilla 2.0, everything was static:

values13

You couldn’t customize bug statuses, resolutions, bug severities, priorities, etc… Now admins have a nice UI to edit them:

values44

Same goes about the list of products, components and assignees:

products13

The list was hardcoded, and you had to manually edit the DB to add/edit/remove entries. Now this can be done from the UI:

products44

The list of parameters also increased a lot, and the ugly old UI…

params13

… became a well organized list of tabs:

params44

Maybe you wonder how other pages looked like in Bugzilla 2.0? Well, there are no other pages. They are all listed above. :) No preferences page, no tabular and graphical reports, and… no groups! Which means no admins, no editbugs nor canconfirm privileges, no way to restrict the visibility of bugs and comments. Frightening, isn’t it? :)

Happy birthday, Bugzilla!

 

Catégories:Bugzilla, Mozilla

It’s time for me to leave the Bugzilla project

"Everything that has a beginning has an end". I joined the Bugzilla project in August 2004 (already 9 years ago) and fixed more than 1600 bugs (including a few bugs in Bonsai, Doctor and Testopia). I became an official reviewer in December 2004, only 4 months after my first contribution, and reviewed patches in more than 2000 bugs. I also got approval privileges in January 2007, meaning that I had the responsibility to grant/deny approval for the last 6.5 years, and approved no less than 1500 patches to be committed into the source code. I’m also the QA manager for the Bugzilla project since July 2005 and so I am responsible to make sure Bugzilla quality is good enough before each new release. That’s a lot of work, and takes a lot of my free time and energy.

In the last few months, my free time was pretty limited and so my contributions to the project were mostly to triage new bugs, set blockers for the next releases, approve (or reject) reviewed patches, and help fixing blockers and security bugs. But now that my free time increased a bit again, I realized that my motivation to write new patches, either bug fixes or new features, and my motivation to review patches in my too long review queue are gone. And to lead a project correctly (I’m actually an assistant project lead, the project lead being justdave), you need to put time and energy into it to not be the bottleneck in the development of the application. And so without enough motivation and energy anymore it’s time for me to resign my role as assistant project lead. This means that decisions about the direction Bugzilla should take no longer belong to me. So please stop marking bugs as WONTFIX because LpSolit (me) said he didn’t agree with such or such new feature; my opinion is no longer relevant. :)

Those who know me shouldn’t be too surprised by my decision. Two years ago, I was very close from taking the same decision. The only reason I didn’t was because mkanat left the Bugzilla project to go work for Google, and it wasn’t the right time to also leave the project. So I stayed involved two additional years to help with the release of Bugzilla 4.2 and 4.4, but now it’s really time for me to say goodbye. This also means you shouldn’t ask me to review your patches anymore. Those should be addressed to another reviewer (glob, dkl, justdave). I will keep my reviewer and QA manager hats for now, but really stop asking me for review (unless it’s a security or critical bug which requires my skills).

It was a really great and fantastic experience to work with other Bugzilla developers and contributors, and I wish all the best for the future of Bugzilla. :)

Catégories:Bugzilla, Mozilla

Bugzilla 4.4 and 4.2.6 released

We released Bugzilla 4.4 and 4.2.6 a few minutes ago. Bugzilla 4.2.6 is a bugfix release, and contains no security fixes. It adds support for MySQL 5.6 and fixes a crash with Oracle.

Bugzilla 4.4 contains many new features:

  • The searching system has been improved: it allows multiple search criteria to match one field; it has improved support for flags; it has better performance, especially with complex queries.
  • The tagging system has been redesigned: the old tagging fields in the page footer are gone in favor of a Tags field in the bug itself. Tags remain private and are only visible by you. They can also be used in queries as any other field.
  • Bugzilla can now correctly identify uploaded attachments which have a MIME type of application/octet-stream.
  • You can now save tabular and graphical reports as you already do with saved searches. Previously, you had to bookmark them in your web browser.
  • You can customize columns displayed in whinemails.
  • As usual, the WebServices have been improved with several new methods.
  • The security has been improved, such as using HMAC SHA-256 to generate tokens instead of MD5.
  • etc ….

This release also means the End Of Life (EOL) of Bugzilla 3.6, which was the last series for Bugzilla 3.x. This branch is no longer supported, and any new security bug found on this branch will remain unfixed. Installations still running Bugzilla 2.x or 3.x are urged to upgrade to Bugzilla 4.4 or 4.2.6.

So, what’s next? Well, the main focus for Bugzilla 5.0 will be usability and user experience. Bugzilla sometimes (often?) looks old-fashioned because we wanted to support old browsers and browsers with JavaScript disabled. But we decided to move to a more interactive interface where JavaScript will help accomplish some tasks with less page reloads, such as submitting changes to a bug or adding an attachment. We also plan to add a new skin to Bugzilla which should look like this. Some pages will also be entirely redesigned, such as the Group Controls page to administrate access to bugs which was considered too complex for the average admin. More information will come with the release of development snapshots.

Catégories:Bugzilla, Mozilla

Bugzilla 4.4rc2 and 4.2.5 released (and also 4.0.10 and 3.6.13)

So, Bugzilla 4.4rc2 is finally here! It took us more time than expected, but the performance bugs are all fixed and we also fixed two security bugs which are described in the security advisory. Bugzilla 4.2.5, 4.0.10 and 3.6.13 also contain these two security fixes, so you should definitely upgrade.

Compared to 4.4rc1, the new release candidate contains the last feature which we wanted for 4.4: the ability to add several criteria in a query against the same field. In Bugzilla 4.2,

"Flags changed to approval+" AND "Flags changed by foo@bar.com"

were disconnected, which means that these criteria would match all bugs which had the approval+ flag set and which had a flag changed by foo@bar.com. In Bugzilla 4.4, you can now force these two criteria to match the same field, i.e. that you only want bugs where the approval+ flag has been set by foo@bar.com. Thanks to Byron Jones (glob) for this great feature. :) Of course, this feature is not limited to flags, but works with all fields. See the release notes for more details. Also, 4.4rc2 should in most cases be much faster than 4.2 to run some complex queries. In my testing, some queries which took several minutes to complete now run in a few (tens of) seconds only. This is especially noticable with many columns displayed in the buglist. Another good reason to test it! ;)

The next release should be 4.4 final as I don’t think a 4.4rc3 is needed.

Catégories:Bugzilla, Mozilla
Suivre

Recevez les nouvelles publications par mail.