Blog
Want to always keep up-to-date with Bugzilla news? Subscribe to announce@bugzilla.org, a read-only mailing list where we'll post announcements about new versions of Bugzilla and security advisories.
You can also see what's going on in the project by looking at the notes of, or watching the video of, our monthly developer meetings.
Loading the upcoming event
Git Migration Scheduled
A migration of Bugzilla and related code from bzr.mozilla.org to git.mozilla.org will be perfomed on Tuesday, 11 March 2014, starting at 17:00 UTC. At this time, all Bazaar branches on bzr.mozilla.org will be made read-only (aside from a few admin accounts), and the migration to git repositories on git.mozilla.org will commence. It should take around 1.5 hours to migrate everything, after which point write access will be enabled on the git repositories for all users previously authorized on bzr.mozilla.org. A script will periodically mirror changes from git to bzr for all currently supported Bugzilla branches (4.0, 4.2, and 4.4). Changes will not be mirrored for any other branches of Bugzilla nor any other related branches (extensions, misc, etc.).
We will start mirroring changes to read-only repositories on GitHub at some point (to be determined) after the migration to git.mozilla.org. git.mozilla.org will remain the repository of record, meaning the only place to which changes should be committed by developers. All mirroring, e.g. to GitHub and bzr.mozilla.org, will be unidirectional.
We’ve already done one test migration; see http://git.mozilla.org. It was successful aside from some missed file deletions, resulting in extra files on a handful of git repositories after the migration. I manually deleted the superfluous files after migration, and I also fixed the migration script to account for this oddity in Bazaar’s fast-export output, so it won’t happen during the real migration.
I would like to open up testing to all developers, starting with another complete, fresh migration, on Tuesday, 18 February 2014, around 17:00 UTC. To test the git-to-bzr mirroring script, we’ll create a new branch, “migration-test”, off of Bugzilla trunk and run the mirroring script on it after the migration. We’ll leave it running until the real migration, and I invite anyone with commit access to bzr.mozilla.org to commit changes to the test-migration branch on git and ensure that they are mirrored properly to bzr.
The full migration and testing plan, along with other details, is at https://wiki.mozilla.org/Bugzilla:Migrating_to_git.
Release of Bugzilla 4.5.2 and 4.4.2
Bugzilla 4.4.2 is our latest stable release. It contains various useful bug fixes:
- Download 4.4.2
- Release Notes for 4.4.2
Bugzilla 4.5.2 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.
Bugzilla considering moving to git
The Bugzilla Project is currently considering moving our source code repository from Bazaar (bzr) to git. Part of the impetus for this is that Mozilla is trying to get out of the business of hosting every version control system known to man (which they currently do, or close to it anyway) and bzr is one of the low-hanging fruit (Bugzilla is the only Mozilla project using it). There’s also a lot of feeling out there that mirroring to GitHub may make contributions easier for new contributors. The general consensus on the thread so far is that we should do it; the main point of contention is how long to keep it mirrored in bzr after it moves.
What’s your take on it? We’d appreciate anyone who currently works on Bugzilla or is contemplating it to join in on the discussion.
The main discussion thread is in a thread on our developers list, and the metabug to track it is bug 929685.
Release of Bugzilla 4.5.1, 4.4.1, 4.2.7, and 4.0.11
Today we have several new releases for you!
All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.
Bugzilla 4.4.1 is our latest stable release. It contains various useful bug fixes and security improvements:
- Download 4.4.1
- Release Notes for 4.4.1
Bugzilla 4.2.7 is a security update for the 4.2 branch and also includes several bug fixes:
- Download 4.2.7
- Release Notes for 4.2.7
Bugzilla 4.0.11 is a security update for the 4.0 branch and also includes several bug fixes:
- Download 4.0.11
- Release Notes for 4.0.11
Bugzilla 4.5.1 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.
Bugzilla Project Meeting Wednesday, July 17th, at 14:00 UTC
Much of this post is taken from a message I posted to the developers list a few days ago, so my apologies in advance to anyone reading it again. I’ve expanded on a few things and added the information about the upcoming meeting, so it’s probably worth re-reading.
For those unaware of the context, Frédéric Buclin last week announced that he was stepping down from his Assistant Project Manager position after 9 years.
To Frédéric: Thanks again (and again!) for all your hard work over the years! As stretched as I’ve been for time myself it has been a true godsend to have you picking up my slack the last few years. You will be missed!
To everyone else: For the time being, I’ll be handling approval requests, so if you have something up for approval and it’s not getting attention, I’m the one to pester.
This is sort of the end of an era for the Bugzilla project… Both Frédéric and Max (who left to work at Google a couple years ago and stepped down from his position earlier this year for lack of time) have been with the project for much longer than most people ever stick with a single employer in IT-related jobs (of which an open source project of this magnitude has a lot of similarities). For an open source project, that’s outright amazing, as people tend to come and go a lot in most projects. It’s kind of surprising that I’ve been around longer than them, but I’m kind of a “lifer” in some ways, and in reality I’ve had a good break from the project for the last few years because Max and Frédéric have been mostly taking care of everything while I’ve been busy with other things.
So it’s time to begin a new era. Since I’ve had a good break to clear the monotony I’m going to be trying to get more involved myself again (which I’ve been saying ever since Max left, but I have a lot more incentive now). I’d also like to kickstart a new team to lead the project, and kind of re-organize if you will. We have a number of positions within the project for various functions, which we’ve never really paid attention to as people moved on. So some questions we’ll be asking at our upcoming meeting are:
- What positions in our existing structure do we have open?
- Do we still need them all?
- Are there new positions we have a need for that we should create?
- Who should fill them?
- Do the existing holders of positions that we still need and haven’t been vacated want to keep doing them?
We also have some other “reinventing the project” type topics while we’re at it. There’s a number of things we’ve been talking about doing for a long time that we never really moved on, and some of the big elusive dreams (the big UI overhaul!) have actually been making progress as well, lately. When we’re in the middle of big changes like this, I think it’s a good time to review where we are, get everyone on the same page, and tackle some of these things we keep talking about.
We also have a lot of new useful technology at our disposal since the last time we had a project meeting. We’re going to experiment with using Google Hangouts for the meeting this time, and using their feature to stream the Hangout via YouTube for those who want to watch without participating. We’ll also keep our usual meeting IRC channel open so people who don’t have a Google+ account and don’t want to get one can still participate and ask questions via IRC.
The preliminary agenda and participation instructions have been posted at https://wiki.mozilla.org/Bugzilla:Meetings. The meeting will be held on Wednesday, July 17th, at 14:00 UTC. And before anyone complains about the time, this was the best time to avoid inconveniencing the largest number of people. The Bugzilla Project has a global pool of contributors, and we have active contributors in a wide variety of time zones. The time chosen puts the meeting in the middle of the night for the fewest number of people. Those on the west coast in the US will probably have to get up a little early, and those in eastern Australia will be up a little later.
A lot of the emails and comments I’ve gotten since Frédéric’s announcement have been really positive, so I’m encouraged by the number of people who are still committed to keeping Bugzilla vibrant! We’ll see you at the meeting on Wednesday!
Release of Bugzilla 4.4 and 4.2.6
Today the Bugzilla Project is extremely proud to announce the release of Bugzilla 4.4!
It has been over a year since we released Bugzilla 4.2 on February 2012, and this new major release comes with several new features and improvements. This release contains major improvements to WebServices, which were our main target in this release, a rewritten tagging system, a real MIME type auto-detection for attachments, improved support for Oracle, performance improvements and lots of other enhancements.
We hope that you enjoy and appreciate the results of this past year of hard work by our entirely-volunteer community.
- Download 4.4
- Release Notes for 4.4
Bugzilla 4.2.6 is a bug fix update for the 4.2 branch:
- Download 4.2.6
- Release Notes for 4.2.6
EOL for 3.6.x
Please note that the release of Bugzilla 4.4 also marks End Of Life for the Bugzilla 3.6 series, meaning that there will be no further updates for the 3.6.x series, even if there are serious security issues found in that series. We recommend that all installations running the 3.6 series upgrade as soon as possible to 4.4.
Release of Bugzilla 4.4rc2, 4.2.5, 4.0.10, and 3.6.13
Today we have several new releases for you!
All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.
Bugzilla 4.4rc2 is our second Release Candidate for Bugzilla 4.4. This release has received QA testing, and should be considerably more stable than the development releases before it. It is still not considered fully stable, and so you should understand that if you use it, you use it at your own risk.
If feedback from this release candidate indicates that it is mostly stable, then Bugzilla 4.4 will be released in a few weeks. If feedback indicates that more extensive fixes are needed, there may be another release candidate after this one.
- Download 4.4rc2
- Release Notes for 4.4rc2
Bugzilla 4.2.5 is our latest stable release. It contains various useful bug fixes and security improvements:
- Download 4.2.5
- Release Notes for 4.2.5
Bugzilla 4.0.10 is a security update for the 4.0 branch:
- Download 4.0.10
- Release Notes for 4.0.10
Bugzilla 3.6.13 is a security update for the 3.6 branch:
- Download 3.6.13
- Release Notes for 3.6.13
Upgrading your Bugzilla? Don't forget to Sanity Check first.
When planning on upgrading your Bugzilla to a newer version, it’s always a good idea to read the release notes in case of special instructions that need to be done to handle certain situations in upgrades. Our checksetup.pl script has gotten pretty good at handling a lot of situations automatically for you these days, but nothing is ever perfect.
One instruction in the upgrade procedure for every release that often gets overlooked is to run the Sanity Check function from the Admin page on your Bugzilla site before upgrading. It checks the integrity of the data in your database and will alert you to a number of possible problems with your data. Sometimes bugs in Bugzilla or even people manually messing with the database will cause something to not be how Bugzilla expects it, and every so often one of these problems can cause issues for an upgrade. Fixing any problems reported by Sanity Check before each upgrade can save you a lot of headaches.
In a recent example: newer versions of Bugzilla allow you to edit the available statuses and resolutions on bugs. Older versions didn’t. One of the steps performed by the upgrade script is to examine your database, take whatever current statuses you’ve been using (even if you hacked your Bugzilla to allow different ones before we actually let you customize them), and convert them to the way the new customizable ones are stored. The new custom status system has a flag to distinguish between statuses that are allowed to have resolutions and those that aren’t. When upgrading, it decides whether to set that flag on a status or not by looking in your database to see if there are any bugs with that status that have resolutions on them. If it finds any, the status is set up to use them.
A long time ago there was Bug 107229 which caused duplicate bugs to get the wrong status if you midaired while marking it a duplicate. This caused bugs to exist in an “ASSIGNED DUPLICATE” state that should have been “RESOLVED DUPLICATE”. A side effect is if it was left that way, when you later upgraded to a version of Bugzilla that included the custom statuses, your ASSIGNED status became a “closed” type instead of an “open” one, and would require a resolution. Sanity Check most likely would have caught this, as it checks for things like resolutions where there shouldn’t be any. :)
Release of Bugzilla 4.4rc1, 4.2.4, 4.0.9, and 3.6.12
Today we have several new releases for you!
All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.
Bugzilla 4.4rc1 is our first Release Candidate for Bugzilla 4.4. This release has received QA testing, and should be considerably more stable than the development releases before it. It is still not considered fully stable, and so you should understand that if you use it, you use it at your own risk.
If feedback from this release candidate indicates that it is mostly stable, then Bugzilla 4.4 will be released in a few weeks. If feedback indicates that more extensive fixes are needed, there may be another release candidate after this one.
- Download 4.4rc1
- Release Notes for 4.4rc1
Bugzilla 4.2.4 is our latest stable release. It contains various useful bug fixes and security improvements:
- Download 4.2.4
- Release Notes for 4.2.4
Bugzilla 4.0.9 is a security update for the 4.0 branch:
- Download 4.0.9
- Release Notes for 4.0.9
Bugzilla 3.6.12 is a security update for the 3.6 branch:
- Download 3.6.12
- Release Notes for 3.6.12
Release of Bugzilla 4.3.3, 4.2.3, 4.0.8, and 3.6.11
Today we have several new releases for you!
All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.
Bugzilla 4.2.3 is our latest stable release. It contains various useful bug fixes and security improvements:
- Download 4.2.3
- Release Notes for 4.2.3
Bugzilla 4.0.8 is a security update for the 4.0 branch:
- Download 4.0.8
- Release Notes for 4.0.8
Bugzilla 3.6.11 is a security update for the 3.6 branch:
- Download 3.6.11
- Release Notes for 3.6.11
Bugzilla 4.3.3 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.