From Bugzilla 2.18 to 4.0 and beyond
Since the release of Bugzilla 4.0 in mid-February, you may have noticed that I strongly reduced my involvement in the Bugzilla project. There are several reasons for this decision:
- I spent so much time at the end of last year and at the beginning of this one in writing and reviewing patches to fix the remaining nasty blockers for 4.0 that I needed some rest. As the QA lead, I also spent a fair amount of time checking all the regressions reported in the last few months and testing Bugzilla 4.0 as much as possible to make sure it was ready for release. Among others, this meant also updating all our automatic QA test scripts (which use Selenium) to correctly run with 4.0.
- I was also involved in several discussions taking place among core developers and managers about the way Bugzilla should go and the way the Bugzilla project is managed, and there are some hot topics where we are far from a consensus. All these discussions take a lot of time and energy too. This is not the right place to give details, though. Those who are concerned by these discussions already know the details.
- The main reason why I joined the Bugzilla team in August 2004 was because there were obvious broken or missing features in the version of Bugzilla available at that time, i.e. Bugzilla 2.18rc2. As the code didn’t look too terrible, I decided to give it a try and fix some bugs myself, and that’s how I started contributing. But as time passed, obvious broken features were fixed, and obvious missing features were implemented. So I then focused on more difficult, but less annoying, bugs and missing features. And with the releases of Bugzilla 4.0 and 4.1.1, I came to a point where all I think was important to have was there. You guess what this means. My motivation to implement new features obviously decreased, mostly because they aren’t trivial to implement and the benefit for users is smaller.
I think now is a good time to see how much I contributed to the project in these last 7 years, and what I achieved during this time. As I was checking this myself today, I thought you may be curious to know what were my main contributions, and so I decided to share the list below. Note that I fixed 1224 bugs in the Bugzilla product, so I’m not going to list them all. Only the outstanding bug fixes and new features are listed below, ordered by release versions:
Bugzilla 2.16 – 4.0
34 security bugs, across all versions.
Bug 206037: There were many places where user data was incorrectly filtered before being displayed in the web browser, which could potentially lead to XSS or break pages entirely. This was a pain to fix all these places, and I had no fun in doing this, but it was necessary to really protect our users.
Other contributions for this release were all bug fixes as Bugzilla 2.18 was already feature frozen when I joined the project.
Bug 180879: Till now, everybody could edit flags in bugs. I implemented permissions for flags so that admins could decide who would be allowed to request a flag, and who would be allowed to grant and deny them. Mozilla uses this feature heavily e.g. for their blocking and approval flags.
Bug 319055: If a bug comment had a "." on its own line, the remaining part of the comment was skipped in bugmails.
In this release, I also helped with the cleanup process to remove all these old %FORM, SendSQL() and other oddities which were in Bugzilla 2.x.
Bug 46296: Till now, all parameters were listed in a single page, making the page ridiculously long and parameters hard to find. I refactored this into separate panels, grouped by topic. I also did it in a way that parameter descriptions could be localized.
Bug 301508: CGI.pl was a kind of black hole with tons of subroutines in it, to achieve many unrelated goals. With the help of other developers, we moved these subroutines into modules, grouped logically. This was a required cleanup to be able to develop new features without adding additional mess to the code.
Bug 313020: I implemented the ability to tag bugs individually. These tags then appeared as normal saved searches in the footer of pages, so that you could easily list all bugs with the same tag.
I also helped with removing stuff from globals.pl, another black hole used in previous releases.
Bug 38862: In order to protect users from malicious attachments, I implemented the ability to specify an alternate host for attachments. You can even set it to have one different host per bug, to avoid attachments from one bug to interact with attachments from another bug. That’s the configuration used e.g. by Mozilla.
Bug 44595: I implemented the ability for admins to delete attachments, e.g. malicious ones, or because they contain confidential data which wasn’t supposed to be attached to the bug.
Bug 87795: When creating a new user account, you now get a token by email to confirm that your email address is valid, rather than assuming that it’s the case and sending the password by email directly. This also lets you choose your password yourself rather than generating a random one automatically.
Bug 92515: When the resolution on a bug is wrong, you can now change it without having to first reopen the bug. In some other bugs, I also fixed several such annoying two-steps processes which were not needed and irritating.
Bug 94534: I implemented the ability for admins to customize the list of bug resolutions. Admins can add/edit/remove resolutions from the web UI directly instead of having to hack the source code to make it work.
Bug 174039: When filing a new bug, you can set flags at the same time, instead of having to file the bug first and then edit it.
Bug 189627: I implemented the ability to give canconfirm, editbugs and editcomponents privs on a per-product basis so that installations with many distinct products can better separate user privileges (and only give privileges for products they are working on).
Bug 274802: Previously, when you were moving a bug from one product which has some given flag types to another product which has a different set of flag types, all existing flags set to the bug were deleted. Now, if the target product has a flag type with the same name as the original product, Bugzilla migrate the old flag to the new one.
Bug 282121: globals.pl is now gone. All subroutines have been moved into their respective modules. At this point, we can say that the old and ugly code has been removed from the source code. Bugzilla 3.0 is born!
Bug 287326: I implemented the ability to add custom single-select fields to bugs. This was the second custom field type being implemented, after free text fields.
Bug 317409: I implemented the ability to hide obsolete attachments in bug reports.
Bug 330487: In Bugzilla 2.x, an admin had to manually check if there were new releases of Bugzilla, or at least watch some mailing-list to get this information. Now, Bugzilla can automatically notify admins when a new release is available.
Bug 340426: It was a pain to be forced to scroll to the bottom of the page to access links such as "New", "Search", "Log in", etc… I duplicated these links to the top of the page to avoid this problem.
Bug 344875: I implemented the ability to create and control custom fields from the web UI. Before that, you had to run a script from the shell.
Bug 354661: I created a search plugin for Firefox 2+ and IE 7+.
Bug 101179: Till now, bug statuses were hardcoded in the source code. Admins can now add/edit/remove them from the web UI. I also implemented the ability to control which transitions were allowed.
Bug 218618: When viewing a patch, line numbers are now displayed, greatly helping to locate code and changes in files.
Bug 304005: Bugzilla is now able to authenticate against a SMTP server to send bugmails.
Bug 182238: Till now, the timezone used to display the timestamp of comments was controlled by the admin. Now, each user can select the timezone of his choice.
Bug 108243: You can now display bug flags in buglists.
Bug 302542: You can now delete series in new charts, either one by one, or when deleting a product.
Nothing exciting from me in this release. I spent most of my time fixing regressions and doing QA. I only implemented minor new stuff.
Bug 119703: You can now create an attachment simply by pasting text into a text field, instead of being forced to attach a file.
Bug 142394: You can now sort columns in tabular reports.
Bug 466968: I did a major cleanup of the mail-generation code. It’s now much easier to extend and customize it, and bugmails are now fully localizable.
Bug 529974: Users with local editcomponents privs, i.e having such privs for some products only, can now also edit flag types for these products. Before that, you had to ask someone with global editcomponents privs to do changes for you.
As you can see, I hacked many different parts of the Bugzilla code, implementing various major features. Now, I came to the point where I think I implemented most things I considered important, from my point of view. I still have one last new feature which is in progress, which is the ability to identify the sender of an email sent to email_in.pl, see bug 419203. I hope to have this feature ready for 4.2. After that, it’s unclear what my contributions to the project will be, if any. There are two additional features which would be great to see being implemented:
- Bug 123130: Let several Bugzilla installations talk to each other, e.g. for dependencies or to get the bug status and resolution of an external bug.
- Bug 55970: Add the ability to better track progress of a bug relative to several branches.
I think those two features together would be great candidates to define what would be called Bugzilla 5.0. But maybe I won’t be around anymore when this happens, as Bugzilla 5.0 isn’t expected before 2012 at the earliest (Bugzilla 4.2 will be released at the end of 2011, and I suppose there will be a 4.4 before 5.0).