Compile DBD::Oracle with Oracle 10g XE + Bugzilla

If you are like me and want to compile DBD::Oracle to use with Bugzilla and your installation of Oracle 10g XE, simply type the following command from the bugzilla/ root directory:
ORACLE_SID=XE
ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server
LD_LIBRARY_PATH=$ORACLE_HOME/lib
./install-module.pl DBD::Oracle

Of course, you must have installed oracle-xe-univ-10.2.0.1-1.0.i386.rpm already. This should save you a few headaches to make it work.

Bugzilla 4.1.3, 4.0.2, 3.6.6 and 3.4.12 released

More than 3 months after our last releases, we finally released Bugzilla 4.1.3, 4.0.2, 3.6.6 and 3.4.12 last night. Bugzilla 3.6.6 and 3.4.12 are security releases for our old supported branches. Bugzilla 4.0.2 contains security fixes and several useful bug fixes, including:

• The Bug.create() WebService method now throws an error if you pass a group name which doesn’t exist. In Bugzilla 4.0 and 4.0.1, this group name was silently ignored, leaving your bug unsecure if no other group applied.
• Moving several bugs at once into another product works again. In Bugzilla 4.0 and 4.0.1, it displayed the same confirmation page again and again, and changes were never committed.
• Marking a bug as a duplicate now works in Internet Explorer 9.
• The XML-RPC interface now works with SOAP::Lite 0.711 and 0.712 under mod_perl.
• and much more!

I strongly recommend to upgrade to 4.0.2, which is much more stable and usable than 4.0 or 4.0.1!

And for those who love to live dangerously, we also released Bugzilla 4.1.3, our lastest development snapshot. It contains all the security and bug fixes mentioned above. As we don’t accept any new features for Bugzilla 4.2 since we released 4.1.2, we focused on fixing regressions and other nasty bugs. Bugzilla 4.1.3 should be much more usable than 4.1.2, even if it’s not production-quality yet. Depending on how things go and the feedback we get, this could be the last development snapshot before 4.2rc1. Note that once Bugzilla 4.2 is released (probably near the end of this year), Bugzilla 3.4 will reach End Of Life and we won’t support this branch anymore.

Latest news about Bugzilla 4.0.2, 4.2rc1 and 5.0

We had another Bugzilla meeting on IRC yesterday (channel log), and the three topics were about Bugzilla 4.0.2, 4.2rc1 and about Bugzilla 5.0. So I’m going to give you a brief summary of what has been discussed.

Bugzilla 4.0.2

We still have a few blockers for 4.0.2. Due to security bugs being under investigation, we are probably going to release Bugzilla 4.0.2, 4.1.3, 3.6.6 and 3.4.12 before we branch for 4.2rc1. ETA: asap (I cannot be more precise as it all depends on our free time, as we are all volunteers; but this should be done in the coming few days or weeks)!

Bugzilla 4.2rc1

The list of blockers for 4.2rc1 is pretty large. Fortunately, they all have a developer assigned to them, and so we can expect some activity there, at least once the security releases mentioned above are out. ETA: several weeks, maybe July?

Bugzilla 5.0

What will come after Bugzilla 4.2 depends on the progress made to redo the UI of Bugzilla, especially about show_bug.cgi, see bug 662605. Once the new UI is complete, we will call Bugzilla 5.0. Meanwhile, we will release Bugzilla 4.4, 4.6, … till the new UI (which is developed in its own branch) is merged with the main tree. Besides the new UI, we defined some main goals for the next release (independently of its version being 4.4 or 5.0), and we will try to fix as many of them during the next development cycle. As major Bugzilla releases are time-based, instead of feature-based, probably not all these enhancements will be implemented on time for the next release. If there is one you really cannot live without, feel free to join us and help implement them. New contributors are always welcome!

Excel, OpenOffice, LibreOffice, or when developers think rules do not apply to them

Before programming, programmers usually go to school at least till the age of 16 (and then there is also high school and university for some of them). During the secondary school, pupils all learn the order of operations in mathematics. In particular, they all learn that -4^2 = -16, because exponents always take precedence over +, -, * and /. There is no exception to this rule, except in the world of spreadsheets, including Excel, OpenOffice and LibreOffice. Here, there are some developers (I hope not all of them) who either never went to school, or preferred to sleep during maths classes. Why? Because in their world, -4^2 = 16. Arghh! In the world of spreadsheets, only Gnumeric developers seem to have gone to school and remember what their maths teachers told them, and Gnumeric works just fine. Oh, and guess what? Scientific tools like Gnuplot and Mathematica also return -16, as well as Perl and Python and probably mostly everything else which exists in the world.

But when you report this bug to the OpenOffice (see also here) and LibreOffice Bugzilla installations, you are considered as being completely dumb:

OpenOffice bug 24271 comment 1:

"you're wrong. The function works according to the
 mathematical rules.

 -4^2 is -4*-4 or 16"

OpenOffice bug 24271 comment 27:

"Result of input '=-2^4' can't be anything else than (-2)^4!
 Here the '-' can't be anything else than an algebraic sign,
 interpretation as a subtraction operator for  '-(2^4) is
 completely useless like a mathematical expression '/3'"

LibreOffice bug 37271 comment 1:

"Imho LibO "intuitively" correctly recognizes the difference
 between a "Sign of a number" ant the subtraction operator. 

 I disagree with reporter's interpretation. [...]
 Please provide information concerning public available
 mathematical sources supporting your thesis."

These last two comments are from the same developer (one who definitely never went to school). The OpenOffice bug has been marked as INVALID, and the LibreOffice bug has been marked as NOTABUG (a synonym but more polite bug resolution to say INVALID). It’s just unacceptable that developers intentionally ignore mathematicals rules which are universally accepted across the whole world, and decide to reimplement their own rules, and then treat users who are totally right as if they said that 1+1=3. A more respectful (but still unsatisfying) bug resolution would have been WONTFIX with the comment that the reporters of the bugs are right, but due to the way Excel works, and for compatibility reasons with Excel, they are forced to do this incorrect statement that -X^2 = (-X)^2. Also, the helper assistant should pop up and warn the user about this misbehavior.

I hope the developers who wrote these comments above are not the ones who write the core code of OpenOffice/LibreOffice! Else I wouldn’t be surprised to discover that 1+1=3 is finally correct too.

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.

Bugzilla 2.18

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.

Bugzilla 2.20

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.

Bugzilla 2.22

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.

Bugzilla 3.0

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+.

Bugzilla 3.2

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.

Bugzilla 3.4:

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.

Bugzilla 3.6

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.

Bugzilla 4.0

Nothing exciting from me in this release. I spent most of my time fixing regressions and doing QA. I only implemented minor new stuff.

Bugzilla 4.2

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).

Debian takes security very seriously… but how?

On http://www.debian.org/security/, I can read:

"Debian takes security very seriously. We handle all security problems brought to our attention and ensure that they are corrected within a reasonable timeframe."

By default, there is no reason to not believe them. But while talking with the administrator of Samba Bugzilla in bug 7121, I realized this was far from being true! What follows is specific to the Bugzilla case, but I guess there are plenty of other similar examples for other Debian packages.

This security report set the urgency to "High", and despite the corresponding bug report has been reported to Debian more than a month ago asking the maintainer of the Bugzilla package to release new versions, nothing has been done so far. Even Secunia marked this security issue as "moderately critical", which is the third level out of five. And I myself emailed the Bugzilla package maintainer at Debian a few days ago, but got no response so far.

So my question is this: how can Debian honestly argue that they take security very seriously? It looks like it takes ages to get something done, which is usually not a big deal when talking about new features, but is definitely a problem when talking about security.

I wanted to know if there were other older unpatched security bugs relative to Bugzilla packages, and I’m a bit irritated to see that there are many! Some of them are two years old! Yes, very seriously!

Bugzilla developers at Mozilla are in no way in charge to maintain these packages, neither for Debian, nor Fedora, nor Mandriva nor any other Linux distro, so we have no control at all on that. And people often come on IRC asking us for help, because their Bugzilla package provided with their Linux distro is broken or behaves in a weird way (typically a broken configuration or customization). And guess what? Most of the time, they use the Debian package. Yes, very seriously! For comparison, Fedora updated their Bugzilla packages the day after we released 3.6.4, and Mandriva the week after! It looks like they take security a bit more seriously.

Stable Bugzilla 4.0 released

We released Bugzilla 4.0 a few minutes ago! It has many new features and improvements compared to Bugzilla 3.x, and comes almost 4 years after Bugzilla 3.0 (which was released in May 2007). With this major release, Bugzilla 3.2 reached End Of Life (EOL) and is now unsupported. Everybody running a version older than 3.4.10 should upgrade to 4.0 to get future security and stability fixes.

Bugzilla 4.0 got full testing from the QA team, and should be considered stable:

All tests successful.
Files=55, Tests=11621, 2473 wallclock secs ( 1.86 usr  0.23 sys + 21.95 cusr  1.66 csys = 25.70 CPU)
Result: PASS

Enjoy!

 

Update: If you get the error "ExpiresActive not allowed" from Apache when upgrading to Bugzilla 4.0, edit your Apache config file httpd.conf as explained in the Bugzilla documentation. Till now, you probably had:

<Directory /var/www/html/bugzilla>
  ...
  AllowOverride Limit
</Directory>

Now the AllowOverride command must be:

  AllowOverride Limit FileInfo Indexes

in order to force the web browser to update its cache with newer CSS and JS files when they change (e.g. when upgrading to a newer release in some months). If Bugzilla 4.0 is working fine without this change, then this means that you either don’t use mod_cgi, or this feature is not enabled in your Apache server.

Update 2: Contrary to what Samuel Gibbs said in his post, we are not dropping support for all versions of Bugzilla 3. As I said above, only support for Bugzilla 3.2 and older is dropped. This means that Bugzilla 3.4 and 3.6 are still supported, at least till the end of the year.

Update 3: Bugzilla 4.2 should be released at the end of this year, if everything goes well.

Bugzilla 4.0rc2, 3.6.4, 3.4.10 and 3.2.10 released

Yesterday (23 hours ago, to be exact), we released new versions of Bugzilla which all include fixes for critical security vulnerabilities. The most critical one is described in CVE-2010-4568 and you can get the patches from bug 621591 for all versions of Bugzilla 3.2 and newer. This means that we provided no patch for Bugzilla 3.0.11 and older, and so if you are running such an old version, then you are in trouble, and you would have to backport the patches to your installation yourself. If you didn’t yet, now would be a good time to decide to upgrade to Bugzilla 3.6.4, or 4.0rc2 which should now be stable enough. You have been warned!

About Bugzilla 4.0rc2, note that this is probably our last release candidate before 4.0 final, which we expect to release mid-February. When 4.0 final will  be released next month, we will also stop supporting Bugzilla 3.2.x. So if you run something older than Bugzilla 3.4.10, then you should really upgrade. Just for your information, Mozilla, GCC and Xfce already upgraded to 3.6.4 today. So this is doable even for large installations.

Some Bugzilla installation stats

If you are curious to know the version running on some well known Bugzilla installations worldwide, I collected this information in a single place: http://lpsolit.wordpress.com/bugzilla-usage-worldwide/. I think this way of doing it is better than writing a new article each summer, as I did for the last three years. This page also lists the approximate number of bugs contained in the DB, to give you an idea how big an installation is.

It’s pretty cool to know that so many large companies and projects use Bugzilla to track their bugs. For instance: kernel.org, RedHat, Novell, Mandriva, Mozilla, WebKit, KDE, GNOME, Logitech, Facebook, GCC, Apache and especially Yahoo! with more than 4 million bugs! I hope even more companies and projects will use Bugzilla in the future.

Bugzilla 4.0rc1 (and 3.6.3) released

Last night, we released Bugzilla 4.0rc1 and Bugzilla 3.6.3, as well as security-fixes only  3.4.9 and 3.2.9.

Bugzilla 4.0rc1 comes 3 months after our latest development snapshot 3.7.3, and is considered stable enough for use in non-critical environments. If nothing serious is found in this release candidate, we will release Bugzilla 4.0 final in a few weeks (probably in December). Else we may release another release candidate if major problems are found. Bugzilla 4.0rc1 comes with many improvements over Bugzilla 3.6, for instance: automatic detection of duplicates when reporting a new bug, improved search and attachment details pages, autocompletion for all user fields (requires JSON-RPC to work on your installation), a new default status workflow, the ability for Bugzilla to remember more than one search at once, several new WebService methods among which the highly desired Bug.update() method, the ability to display multi-select custom fields as a column in bug lists (including bug flags!), and many new code and template hooks to help you write extensions without having to hack the core code.

Bugzilla 3.6.3 is our latest stable release, which includes several bug fixes as well as three security fixes, as described in the security advisory. It contains no new features.

Note that once Bugzilla 4.0 is released, we won’t support the 3.2.x series anymore. Installations running such old versions should upgrade to either 3.6.3 or 4.0 final when it comes out.

Make Bugzilla work with IIS7… easy!

It’s usually easier to make Bugzilla work with Apache, but IIS7 made things a lot easier than in previous versions, and it’s now pretty trivial to make it work with IIS too. The screenshots below are in french, but I guess you can understand what needs to be done.

Only two actions are needed, as shown above. Two new panels will be displayed:

 

 

That’s it! Bugzilla should work fine now.

Bugzilla is now available in 10 languages

Our latest stable release, Bugzilla 3.6.2, is now available in 10 languages: bg, cs, de, en, es-es, fr, ja, pl, pt-br, and zh-tw. No idea what happened to the russian team, which disappeared soon after 3.5.2. No idea either for the belarusian team, which stopped releasing new templates after 3.2.3. If you don’t want to install the l10n templates yourself, but you want to see how Bugzilla looks like in other languages, you can play with this test installation, which has all the available l10n templates installed.

GCC Bugzilla upgraded to 3.6.2+

For those who use GCC Bugzilla and Sources Bugzilla (sourceware.org), please note that they have both been upgraded to 3.6.2+ (Sources Bugzilla was running 2.17.5 two hours ago, haha).

Bugzilla 3.6.2, 3.4.8, 3.2.8, and 3.7.3 released

We released Bugzilla 3.6.2, 3.4.8, 3.2.8, and 3.7.3 last night! They all contain fixes for 4 security bugs, and Bugzilla 3.6.2 and 3.7.3 also include numerous bug fixes. Bugzilla 3.6.2 is our most stable release, and is the recommended version to use in production. Bugzilla 3.7.3 is a development snapshot to let you test what will become Bugzilla 4.0. Bugzilla 3.7.3 is now feature complete, and I hope our next release on the 4.0 branch will be 4.0rc1, assuming we manage to fix all remaining blockers (18 blockers as of today). There is no ETA for 4.0rc1 yet, but probably around September or October, if everything goes well. Note that many bugs and regressions are being found in 3.7.x, so you shouldn’t use Bugzilla 3.7.3 in production (but we would be happy that you install it in a test environment and help us catch remaining bugs and regressions before we reach the release candidate phase).

Bugzilla 3.7.3 being feature complete, and no major changes in templates being expected, now is also a good time for localizers to start their work on the 4.0 branch. Once you are ready, feel free to ping me on IRC (nick: LpSolit), or leave a comment to this post with a URL to your website, and I will add it to our list of available localized tarballs (of course, if you have checkin privs, you can update the list yourself). For new localizers, please don’t waste your time translating Bugzilla 3.2.8 or 3.4.8. Bugzilla 3.2 will reach End Of Life at the end of the year or early next year, when Bugzilla 4.0 is released, and Bugzilla 3.4 should reach EOL at the end of next year. Focusing on Bugzilla 3.6 and 4.0 only is a better way to spare some time.

Don’t name your file "attachment.txt" or IE8 will make you crazy

While reviewing and testing a patch for Bugzilla, I spent tens of minutes looking at and playing with IE8 parameters to configure it to display text files inline, i.e. from the web browser directly. I couldn’t figure out why it was unable to display a simple text file. As Google was unhelpful, I had to figure it myself. The reason is crazy: the file I attached to Bugzilla was named "attachment.txt", and due to the word "attachment", IE8 automatically wants to download the file! If I rename the file to e.g. "file.txt" or "bazooka.txt", it works fine again and displays the text file inline, as desired. If you don’t believe me, try yourself and open the two attachments I put here on landfill.

What’s new in Bugzilla 4.0 and 4.2?

I didn’t blog for a long time about new features in the coming Bugzilla 4.0, nor Bugzilla 4.2 whose development just started. So here are some highlights:

Bugzilla 4.0:

• Bug 521416 – Older versions of IIS were causing Bugzilla to crash under some circumstances, due to problems with undefined values being passed back to Bugzilla when they shouldn’t (neither IIS 7.5 nor Apache are affected. IIS 5.1 definitely is. Not sure about IIS 6 and 7). This problem is now fixed, and all versions of IIS should work correctly now. This fix has also been backported to Bugzilla 3.6.2.
• Bug 490923 – Enable autocompletion for the assignee, QA contact, and CC fields. No need to remember the full email address of another user, Bugzilla will now show you a list of users matching the string you entered.
• Bug 412074 – Bug.add_attachment is a new WebService method which lets you add attachments to a bug.
• Bug 415813 – Bug.update is a new WebService method which lets you edit all aspects of an existing bug. Combined with Bug.add_attachment mentioned above, you can do everything you want with bugs. For the record, Bug.create already exists for a long time, to create new bugs.
• Bug 486292 – The default workflow has been changed. New installations will now have UNCONFIRMED, CONFIRMED, IN_PROGRESS, RESOLVED and VERIFIED as bug statuses instead of the old UNCONFIRMED, NEW, ASSIGNED, REOPENED, RESOLVED, VERIFIED and CLOSED bug statuses. You are of course free to edit them from the administrative pages if you don’t like the new default workflow.
• Bug 22353 – Automatic duplicate bug detection has been implemented when filing a new bug, to give you a chance to see existing bugs matching your data before reporting your own bug. We hope this will decrease the number of duplicates.
• Bug 556422 – The existing bug-moving functionality has been converted into an extension which is disabled by default. So this functionality is still present in Bugzilla 4.0, but you now have to enable it by deleting the "extensions/Voting/disabled" file instead of enabling it from the "Parameters" page. Once the extension is enabled, you have to re-run checksetup.pl again.
• Bug 24896 – Bugzilla now supports multiple (by default: 10) buglists at once, meaning that if you edit a bug and click the "Show last search results" link, it will show you the list the bug came from, even if you did another search meanwhile. Note that Bugzilla does its best to guess which buglist a bug comes from. And if a bug appears in several buglists, there is a risk that it redisplays the "wrong" buglist.

Bugzilla 4.2:

• Bug 119703 – You can now create an attachment by pasting text directly into a text field. This means you don’t need to save your text in a file first, which you then have to upload. This is very useful e.g. if you want to copy and paste something very quickly.
• Bug 142394 – Tabular reports are now sortable (requires JS to be enabled). You can choose the column you want to sort data.

As many new, and sometimes invasive, features have landed, we need as much feedback and testing as possible. So do not hesitate to download development snapshots and report bugs if you find something wrong. Remember that these development snapshots are for testing purposes only, and should in no case be used in production (we have a huge list of blockers for 4.0!).

Please upgrade!

For the third consecutive summer, I wanted to know which version major Bugzilla installations were running. In parentheses is the Bugzilla version they were running one year ago. As you can see, only the half of these installations have been upgraded in the last 12 months, and one third runs a version which is no longer supported and which has unpatched security holes. I know Yahoo! plans to upgrade to 3.6 later this year, but I have no idea about the other ones. Remember that Bugzilla 3.0.9 and older are no longer supported, and that we will stop supporting 3.2.x once Bugzilla 4.0 is released (end of this year/beginning of next year).

• Mozilla: 3.6.1+ (3.2.4)
• OpenSSH: 3.6.1 (3.2.3)
• RedHat: 3.4.7+ (3.2.3+)
• Gnome: 3.4.6+ (2.20.5)
• FreeDesktop: 3.4.6 (3.0.8)
• Apache: 3.4.6 (3.2.3)
• Wikimedia: 3.4.5 (3.0.8)
• ClamAV: 3.4.5 (3.4rc1)
• Eclipse: 3.4.4 (3.0.4)
• Novell: 3.4.3 (3.2.2)
• W3C: 3.2.6 (3.0.4)
• KDE: 3.2.5+ (3.2.3+)
• WebKit: 3.2.3 (unchanged)
• Wine: 3.2.3 (unchanged)
• Mandriva: 3.2.3 (unchanged)
• kernel.org: 3.2.2 (unchanged)
• Songbird: 3.0.9 (3.0.5)
• Facebook: 3.0.4 (unchanged)
• ActiveState: 3.0.3 (unchanged)
• Itos (NASA): 3.0.2 (unchanged)
• Gentoo: 2.22.7 (2.22)
• Samba: 2.22.1 (unchanged)
• Maemo: 2.22.1 (unchanged)
• Yahoo!: 2.22.1 (unchanged)
• GCC: 2.20+ (unchanged)

Good bye Windows 2000

… and thank you! Today, Windows 2000 reached End Of Life (EOL). This was a great OS, and I used it till a few months ago when I decided to upgrade to Windows 7, skipping both Windows XP and Vista.

Installing DBD::mysql: what a pain!

I wanted to test Bugzilla on Windows 7 using Perl 5.12.0. I first installed ActivePerl 5.12.0. Unfortunately, DBD::mysql is missing from the PPM repository. So I installed Microsoft Visual C++ 2010 express to use nmake.exe and compile DBD::mysql myself, but it keeps throwing errors:

C:\Users\buclin\Downloads\dbd-mysql>"\Program Files\Microsoft Visual Studio 10.0\VC\bin\nmake.exe"

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. Tous droits réservés.

syntax error at -e line 1, near "’755′)"
Missing right curly or square bracket at -e line 1, at end of line
Execution of -e aborted due to compilation errors.
NMAKE : fatal error U1077: ‘C:\Perl\bin\perl.exe’ : code retour ’0xff’
Stop.

I then installed Strawberry Perl 5.12.0, which already has DBD::mysql, but now I get the following error when accessing Bugzilla from the web browser:

Software error:

install_driver(mysql) failed: Can’t load ‘C:/strawberry/perl/vendor/lib/auto/DBD/mysql/mysql.dll’ for module DBD::mysql: load_file: Le module spécifié est introuvable at C:/strawberry/perl/lib/DynaLoader.pm line 200.
at (eval 938) line 3
Compilation failed in require at (eval 938) line 3.
Perhaps a required shared library or dll isn’t installed where expected
at Bugzilla/DB.pm line 1095

I wasted several hours playing with ActivePerl, Strawberry Perl and Visual C++, with no success. Someone, please compile DBD::mysql successfully and put it in the ActivePerl PPM repository! Thanks!

Bugzilla 3.6 released

We released a new major version of Bugzilla today! Bugzilla 3.6 is coming out less than 9 months after Bugzilla 3.4. This release also means that we no longer support Bugzilla 3.0.x, which reached End Of Life. So if you still use Bugzilla 3.0 or older (Bugzilla 2.x, argh), you should really upgrade, not only to use great new features, but also to protect yourself and your users from possible security attacks!

If you are running Windows and you want to try/test/evaluate Bugzilla 3.6, this is now as simple as dowloading Bugzilla-Setup-3.6.exe and execute the installer. It will install Perl, Apache, MySQL and Bugzilla for you (in a separate C:\Program Files\Bugzilla\ directory, so that they do not interfere with your existing copies of Perl & co), and asking you the minimum required information to have it work immediately. And if you want to uninstall it later, just select Bugzilla in the usual "Add/Remove Applications" panel, and installed applications will go away, with no interaction with existing copies (so if you already have e.g. MySQL installed, the Bugzilla uninstaller will leave it alone, and will only remove the copy of MySQL it installed under C:\Program Files\Bugzilla\). Note that the Windows installer is not officially supported by the Bugzilla team, and is only provided by one of the Bugzilla developers to help people install Bugzilla on Windows.

So now that Bugzilla 3.6 is released, what is coming next? Well, we are already working on the next major release, Bugzilla 3.8, which should bring some highly wanted features, such as a WebService API to edit existing bugs (we will call this method Bug.update), so that you can alter them after having used the already implemented Bug.create method. We are also working on a better support for branches, which will better let you know the status of a bug on a per-branch basis. And we also plan to implement the ability to collect information about remote bugs living in other bug trackers (either Bugzilla or Launchpad.net or Google Code, for instance) and display this information in your Bugzilla itself (I’m talking about improving the "See Also" field in show_bug.cgi, for those who know what it is). If we manage to implement all three features on time, i.e. this summer at the latest, we will skip "Bugzilla 3.8" in the versioning and rename it "Bugzilla 4.0", as it would be a super-major release. Basically, Bugzilla 4.0 would be able to "talk" to each others and interact together.