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
Release of Bugzilla 5.2, 5.0.4.1, and 4.4.14
posted by Dave Miller - Bugzilla Project Lead
This has been a long time coming. Just over a year since we announced the new nonprofit to manage Bugzilla, we finally have a set of releases to show for it. Our only excuse is that the lead developer is a volunteer, has been working almost (but not quite) alone on it, and still has to juggle his normal paying job. A little more about what can be done about that below. First let’s get to the big news!
The Releases
Here’s what we’re releasing today:
4.4.14 – The 4.4 branch has been on life support for a LONG time (it was initially released in 2013!!!). It supports outdated OSes that are hard to find or install, let alone test for these days, and we’ve been itching to drop it for a long time. But our support policy says that we have to support it for 4 months after the following two major releases. The next major release after 4.4 was 5.0, and there have been no major releases after that until today. That four month countdown to End-of-Life starts NOW. This will be the final release of the 4.4 branch (barring any additional security issues being found in the next 4 months).
5.0.4.1 – Why 5.0.4.1 when there’s a 5.0.6 release? Well, if you paid attention to the change logs, 5.0.5 and 5.0.6 contained a massive schema change, as well as reformatting almost all of the Perl code in the source, both of which are a violation of our support policy for a stable branch (a new-to-the-process release manager pushed the release out not realizing that, and by the time we caught it, it was too late). A lot of people noticed this and never upgraded to 5.0.5 or 5.0.6, since they didn’t contain any security fixes. 5.0.4.1 will give those people additional fixes for 5.0.4 without forcing them to pick up those schema and code reformatting changes. Additional updates to the 5.0 branch from now on will continue from 5.0.4.2 and onward.
5.2 – This is our new stable release, and starts the 4 month countdown for discontinuing the 4.4 branch. 5.2 is forked from the 5.0 branch after 5.0.6, and will contain those schema and code formatting changes from 5.0.5 and 5.0.6 in it. So if you did upgrade to 5.0.6, 5.2 will be equivalent to a point upgrade for you. Those schema changes should have caused a major release to happen anyway, so this is just fixing the numbering problem with that release (i.e. 5.0.5 should have been called 5.2 to begin with). Note that if you are using the 5.1.x development releases, those did NOT feed into this, and 5.2 would actually be a downgrade for you.
5.3.3 – In order to avoid confusion with 5.2 above, the 5.1 branch has been retroactively renumbered to 5.3. It is also basically dead, as we’ve put all of our resources into finishing off the Harmony release (see 5.9.1 below). We’re going to encourage people on 5.1.x/5.3.x to move to Harmony, but you’ll want to be mindful of the release blockers first before you make the jump. There are some features in 5.1.x/5.3.x that were implemented differently in Harmony, and the code to migrate the related data may or may not work yet (if the feature in question is listed on the release blockers and you use it, you’ll want to wait for now). Even though this branch is dead, we’re put out this release with the current batch of security fixes so you aren’t left high and dry before Harmony is ready for you.
5.9.1 – This is the first official release off the Harmony branch, and is classified as a developer preview release, not for production use. This is what will eventually be Bugzilla 6. The code is mostly good enough to use right now, but there are still showstoppers to be able to fully release it as a production release. There are also a few gotchas when upgrading from older versions of Bugzilla. If you’re interested in helping make Bugzilla 6 happen, that list of showstoppers is here. We are hoping to have Bugzilla 6 in release candidate stage (or at least in beta) within the next few months.
Download
Bugzilla is available at:
https://www.bugzilla.org/download/
Release Notes & Changes
Before installing or upgrading, you should read the Release Notes for this version of Bugzilla:
It is VERY IMPORTANT to read the Release Notes if you are upgrading from one major version to another (like 4.4.x to 5.0.x).
You can also get a link to see a list of all changes between your version of Bugzilla and the current version of Bugzilla on the above pages.
Staying up-to-date with Bugzilla
You can see the latest updates from the Bugzilla Project and the status of Bugzilla development on the News page of the Bugzilla website.
You can also follow us on our social media:
Live streaming content
Bugzilla now has a Twitch channel! We will be streaming things like work sessions, triage parties, and tutorial content. Can’t make the scheduled live streams? You can watch the Video On Demand recordings on our YouTube channel. Regular streams are at 1pm US Eastern time on Saturdays. We may also stream at other random times.
Report Bugs
If you find a bug in Bugzilla, please report it!
Support
You can ask questions for free on the mailing lists (or in online chat rooms) about Bugzilla, or you can hire a paid consultant to help you out:
Immediate Help Wanted
- Section 508 Compliance Audit. There are a number of US government agencies who use Bugzilla internally (NASA is a publicly visible example). New US government projects have to comply with the new accessibility guidelines in Section 508 of the Communications Act, so if we want them to be able to upgrade we need to comply (at least in our newer versions). See https://section508.gov/. There is a template for a compliance statement at https://www.section508.gov/sell/vpat/. I would love to get a volunteer (or a company who can sponsor someone?) who could audit the 5.2 and harmony branches for compliance, file bugs for things that are violations, and figure out how much of the VPAT we can actually provide at this point. Even if we’re not compliant yet (I suspect we aren’t) I would love to be able to provide a statement with the 5.2 release saying how compliant we are, and listing what’s left to be fixed to make us compliant. See also Bug 1785941. Some work has been done on this (as you can see in the dependent bugs to that one) but it still needs help.
Ongoing Help Wanted
You can always find a list of ways to contribute to Bugzilla on our Contributing page. A few highlights with additional details:
- Donate Money. Now that we have a legal entity capable of paying developers, we need money to pay them with (and also cover our server hosting expenses). See our Donation page to learn how!
- Bug Triage! As you probably noticed from the lack of updates around here in a while, the bug list hasn’t been getting paid much attention to, either. Part of getting this project moving again means re-triaging the existing bug reports. Some of them are really ancient and may not even apply to the current code-base anymore. I’m going to have a blog post coming in the next week or two with information on this topic (specifics for how to help with it), so keep an eye out for that post!
- Code! Once we get the above triage moving, there will be bugs to fix! Bugzilla is an Open Source project, and anyone can contribute! We also have a relatively small user base compared to some of the big projects out there, so the amount of development we’ll be able to fund internally from our donations will still be limited. It will probably make better sense for us to use our internal developers (once we have money to pay some) to review patches and coach external contributors, instead of having them directly producing code.
- Paid Developer Time. If you are a business that makes use of Bugzilla, and has a staff person responsible for maintaining your Bugzilla installation, and that person is willing, please consider officially sponsoring that person to help with upstream Bugzilla development for at least a few hours per week. Most of our lack of development lately has happened because the last few companies that used to do that stopped providing developer time during the economic downturn a few years back (either laid off said person or pulled them away to work on other things), and they haven’t returned. The developers we have currently (until we get money donated as listed above) are all volunteer, and most of them are struggling to find time to work on it.
In Conclusion
We have a lot of excitement ahead of us with the first developer preview of Bugzilla 6, and the new opportunities in store for us with a real business entity to support the project now. Come find us in any of our chat rooms (links are in the footer of our website alongside the social media links) or drop in on our developers mailing list if you’d like to help.
About Bugzilla
Bugzilla is a “Defect Tracking System” or “Bug-Tracking System.” Defect Tracking Systems allow individuals or groups of developers to keep track of outstanding bugs in their product effectively. Most commercial defect-tracking software vendors charge enormous licensing fees. Despite being “free”, Bugzilla has many features its expensive counterparts lack. Consequently, Bugzilla has quickly become a favorite of thousands of organizations across the globe, and is widely regarded as one of the top defect-tracking systems available.
See https://www.bugzilla.org/about/ for more details.
Bugzilla Celebrates 25 Years With Special Announcements
posted by Dave Miller - Bugzilla Project Lead
Happy 25th Birthday to Bugzilla!
Today, August 26, marks the 25th anniversary of Bugzilla!
The first two paragraphs lifted from our Bugzilla history:
When mozilla.org first came online in 1998, one of the first products that was released was Bugzilla, a bug system implemented using freely available open source tools. Bugzilla was originally written in TCL by Terry Weissman for use at mozilla.org to replace the in-house system then in use at Netscape. The initial installation of Bugzilla was deployed to the public on a mozilla.org server on April 6, 1998.
After a few months of testing and fixing on a public deployment, Bugzilla was finally released as open source via anonymous CVS and available for others to use on August 26, 1998. At this point. Terry decided to port Bugzilla to Perl, with the hopes that more people would be able to contribute to it, since Perl seemed to be a more popular language. The completion of the port to Perl was announced on September 15, 1998, and committed to CVS later that night.
25 years is a long time in the software world, and it makes us happy that so many people still use Bugzilla to track bug reports and feature requests for their own products. We hope to continue to breath life into Bugzilla and continue to modernize it over the years to come!
New Legal Entity to Manage the Bugzilla Project
Back in December I made an enthusiastic post about getting Bugzilla back in motion after it kind of stalled for a while. And then after a month I kind of stopped posting about it. So what happened?
Well, response to that post was actually pretty enthusiastic in itself. I heard from several people who wanted to donate money to the project to get it going again. Which then led to a new problem: we didn’t actually have a legal way to accept donations at the time. So after asking around a bit, and a few conference calls between myself, my own company’s lawyer, and a couple of Mozilla’s lawyers, it was decided that Bugzilla needed a legal entity to manage it, similar to how Thunderbird has been operating recently. And, that’s where the little bit of time that I’ve had to spend on Bugzilla has gone the last 6 months. And as you can understand, with the legal work going on in the background, there wasn’t much I could actually talk about until all of the pieces were actually in place.
Which now brings us to today, when I’m happy to announce the formation of Zarro Boogs Corporation, which will now be overseeing the Bugzilla Project. This is a taxable non-profit non-charitable corporation - we have filed with the IRS our intent to operate under US Tax Code §501(c)(4) (still pending approval from the IRS) meaning the IRS would require us to spend money raised on project expenses and not make a profit, but money donated to us will not earn you a tax deduction because we aren’t a charity (software development is not considered a charitable cause in the US). Unlike Thunderbird, which is a subsidiary of the Mozilla Foundation, we are an independent entity not owned by or associated with the Mozilla Foundation, although they have licensed the use of the Bugzilla trademark to us.
The name Zarro Boogs Corporation is a shout-out to the phrase returned by Bugzilla when you run a search which returns no results, “Zarro Boogs found.” The buggy spelling of “Zero Bugs” being intentional because it’s generally believed that there’s no such thing as a project with zero bugs in it, only bugs that haven’t yet been reported, thus, saying “Zero Bugs” is, in itself, buggy. There’s a nice write-up of this on Wikipedia.
If you would like to contribute to the project, we have a donation page set up on GitHub Sponsors. We hope to have additional ways to donate that don’t require a GitHub account in the future.
Upcoming Releases
Those releases I talked about back in December are finally happening! Look for these (except for 5.9.1) this coming week! Right now we’re aiming for Wednesday, August 30th. We are aiming for September 15 for 5.9.1 (because it’s the 25th anniversary of the port from Tcl to Perl).
4.4.14 – The 4.4 branch has been on life support for a LONG time (it was initially released in 2013!!!). It supports outdated OSes that are hard to find or install, let alone test for these days, and we’ve been itching to drop it for a long time. But our support policy says that we have to support it for 4 months after the following two major releases. The next major release after 4.4 was 5.0, and there have been no major releases after that, which means that 4 month countdown hasn’t even started yet. I am intending this to be the final release of the 4.4 branch (barring any additional security issues being found in the next 4 months) as the 5.2 release below will start that 4 month countdown to End-of-Life this branch.
5.0.4.1 – Why 5.0.4.1 when there’s a 5.0.6 release? Well, if you paid attention to the change logs, 5.0.5 and 5.0.6 contained a massive schema change, as well as reformatting almost all of the Perl code in the source, both of which are a violation of our support policy for a stable branch (a new-to-the-process release manager pushed the release out not realizing that, and by the time we caught it, it was too late). A lot of people noticed this and never upgraded to 5.0.5 or 5.0.6, since they didn’t contain any security fixes. 5.0.4.1 will give those people additional fixes for 5.0.4 without forcing them to pick up those schema and code reformatting changes. Additional updates to the 5.0 branch from now on will continue from 5.0.4.2 and onward.
5.2 – This will be the next major release, and will start the 4 month countdown for discontinuing the 4.4 branch. 5.2 is forked from the 5.0 branch after 5.0.6, and will contain those schema and code formatting changes from 5.0.5 and 5.0.6 in it. So if you did upgrade to 5.0.6, 5.2 will be equivalent to a point upgrade for you. Those schema changes should have caused a major release to happen anyway, so this is just fixing the numbering problem with that release (i.e. 5.0.5 should have been called 5.2 to begin with). Note that if you are using the 5.1.x development releases, those did NOT feed into this, and 5.2 would actually be a downgrade for you.
5.1.3 – The 5.1 branch is basically dead, as we’ve put all of our resources into finishing off the Harmony release (see 5.9.1 below). We’re going to encourage people on 5.1.x to move to Harmony, but you’ll want to be mindful of the release blockers first before you make the jump. There are some features in 5.1.x that were implemented differently in Harmony, and the code to migrate the related data may or may not work yet (if the feature in question is listed on the release blockers and you use it, you’ll want to wait for now). Even though this branch is dead, we’re going to put out a release with the current batch of security fixes so you aren’t left high and dry before Harmony is ready for you.
5.9.1 – Coming September 15! This will be the first official release off the Harmony branch, and will be classified as a developer preview release, not for production use. This is what will eventually be Bugzilla 6. The code is mostly good enough to use right now, but there are still showstoppers to be able to fully release it as a production release. There are also a few gotchas when upgrading from older versions of Bugzilla. If you’re interested in helping make Bugzilla 6 happen, that list of showstoppers is here. We are hoping to have Bugzilla 6 in release candidate stage (or at least in beta) by the end of November. The security content for this branch that goes with the other branch releases will be committed to git at the same time the other releases get them, since anyone who has this already will only have it via git pull.
Immediate Help Wanted
- Documentation. Harmony (5.9.1) in particular needs a LOT of documentation help, as what’s there now is pretty specific to trying to produce a testing environment for bugzilla.mozilla.org, rather than a standalone Bugzilla.
- Section 508 Compliance Audit. There are a number of US government agencies who use Bugzilla internally (NASA is a publicly visible example). New US government projects have to comply with the new accessibility guidelines in Section 508 of the Communications Act, so if we want them to be able to upgrade we need to comply (at least in our newer versions). See https://section508.gov/. There is a template for a compliance statement at https://www.section508.gov/sell/vpat/. I would love to get a volunteer (or a company who can sponsor someone?) who could audit the 5.2 and harmony branches for compliance, file bugs for things that are violations, and figure out how much of the VPAT we can actually provide at this point. Even if we’re not compliant yet (I suspect we aren’t) I would love to be able to provide a statement with the 5.2 release saying how compliant we are, and listing what’s left to be fixed to make us compliant. See also Bug 1785941. Some work has been done on this (as you can see in the dependent bugs to that one) but it still needs help.
Ongoing Help Wanted
You can always find a list of ways to contribute to Bugzilla on our Contributing page. A few highlights with additional details:
- Donate Money. Now that we have a legal entity capable of paying developers, we need money to pay them with (and also cover our server hosting expenses). You can donate via our GitHub Sponsors page. If you don’t have and can’t create a GitHub account, we hope to have other ways to donate in the future.
- Bug Triage! As you probably noticed from the lack of updates around here in a while, the bug list hasn’t been getting paid much attention to, either. Part of getting this project moving again means re-triaging the existing bug reports. Some of them are really ancient and may not even apply to the current code-base anymore. I’m going to have another blog post coming in the next day or two (for real this time) with information on this topic (specifics for how to help with it), so keep an eye out for that post!
- Code! Once we get the above triage moving, there will be bugs to fix! Bugzilla is an Open Source project, and anyone can contribute! We also have a relatively small user base compared to some of the big projects out there, so the amount of development we’ll be able to fund internally from our donations will still be limited. It will probably make better sense for us to use our internal developers (once we have money to pay some) to review patches and coach external contributors, instead of having them directly producing code.
- Paid Developer Time. If you are a business that makes use of Bugzilla, and has a staff person responsible for maintaining your Bugzilla installation, and that person is willing, please consider officially sponsoring that person to help with upstream Bugzilla development for at least a few hours per week. Most of our lack of development lately has happened because the last few companies that used to do that stopped providing developer time during the economic downturn a few years back (either laid off said person or pulled them away to work on other things), and they haven’t returned. The developers we have currently (until we get money donated as listed above) are all volunteer, and most of them are struggling to find time to work on it.
In Conclusion
We have a lot of excitement ahead of us with the first developer preview of Bugzilla 6 coming later this week (I was hoping to have that for you all today as well, but we didn’t quite make it), and the new opportunities in store for us with a real business entity to support the project now. Come find us in any of our chat rooms (links are in the footer of our website alongside the social media links) or drop in on our developers mailing list if you’d like to help.
Upcoming releases and more fun stuff
posted by Dave Miller - Bugzilla Project Lead
Surprise! Bugzilla’s not dead yet. :-)
So I posted a bunch of this a few months ago on the developers mailing list but it’s time to get it in front of a bigger audience. :-)
I am trying to kick-start getting stuff moving again with Bugzilla since most of the core Bugzilla volunteers have had job changes over the last few years that have left them with less time to spend on the project, so things have been very slow going for a while. For those that don’t know, I’ve been more or less of a figurehead of a project leader for a number of years now, not having much time to spend on Bugzilla, but not having anyone in a position to be able to step in to replace me, and only stepping in myself to make decision calls when the other developers were at an impasse. I’ve attempted to hand off control of the project to someone else twice in the last 10 years or so, and both times, the person I was about to hand off to got a new job and didn’t have time for it anymore just before we were about to do the hand-off (on the plus side, that happened before they took over and not after). It takes a while for someone to build the trust needed to know I’m leaving it in good hands, so without a lot of active developers it’s hard to get someone in place to do that. But I’ve had some life changes of my own now, which actually give me more time to spend on Bugzilla finally, so I’m getting back in the saddle and taking direct control again. I’ve probably poked at it more in the last 5 or 6 months than I have in the last 5 or 6 years combined.
I have started a new consulting business, and I’ve been trying to structure it in a way that allows me to spend time on Bugzilla again. (If you want to hire me to help with your Bugzilla, or help funding work on upstream Bugzilla, feel free to contact me, even if I’m not publicly advertising yet)
Now back to the nitty gritty and my plans for this project.
There is a call for help in this post below the release information. If you can give us a hand it would be greatly appreciated. Not all of it is code-related, so there might be something you can do even if you’re not a coder!
Infrastructure Updates
Prior to a few weeks ago, our main website hadn’t been updated beyond quick bugfixes to content in a long time. LCP recently did a full overhaul of the website to modernize it and make information easier to find. We deployed this a few weeks ago, so go have a look! It looks awesome! It also has RSS feeds!
Also over the last couple months, I’ve been working on getting some of the project infrastructure back in place to help support active development. Among the list of things that have gotten done are:
- getting our testing suite moved into GitHub Actions so that it runs automatically on every commit
- updating our IRC bot, both to get it to talk to the IRC server again (which it stopped doing recently due to outdated SSL versions), and to update the mail parsing code in it to handle newer versions of Bugzilla (most importantly bugzilla.mozilla.org, where our own notification emails would be coming from).
- Setting up a private Git repository for security commits so that we can stage and test them prior to release without exposing them to the public prior to disclosures.
The Release Plans
I would like to put out a new multi-branch release of Bugzilla as soon as we can get all the pieces in place to do so. I was hoping to do this within a few weeks of the original post to the developers list, but that was back in August and it hasn’t happened yet. At this point I think we’ll be really lucky if it happens before the end of December; though mid-January is definitely a possibility. As a forewarning to everyone, there will be security content in it, and that’s part of the holdup. For obvious reasons I can’t ask for help with the security bugs outside of the existing core developer team, as that risks exposure to hackers that might take advantage of it before users have a chance to update. So we ask for your patience while we work through these issues and get them ready to land.
The 4.4 branch has been on life support for a LONG time (it was initially released in 2013!!!), supports outdated OSes that are hard to find or install, let alone test for these days, and we’ve been itching to drop it for a long time. But our support policy says that we have to support it for 4 months after the following two major releases. The next major release after 4.4 was 5.0, and there have been no major releases after that, which means that 4 month countdown hasn’t even started yet.
4.4.14 - I am intending this to be the final release of the 4.4 branch (barring any additional security issues being found in the next 4 months) as the 5.2 release below will start that 4 month countdown to End-of-Life this branch.
5.0.4.1 - Why 5.0.4.1 when there’s a 5.0.6 release? Well, if you paid attention to the change logs, 5.0.5 and 5.0.6 contained a massive schema change, as well as reformatting almost all of the Perl code in the source, both of which are a violation of our support policy for a stable branch (a new-to-the-process release manager pushed the release out not realizing that, and by the time we caught it, it was too late). A lot of people noticed this and never upgraded to 5.0.5 or 5.0.6, since they didn’t contain any security fixes. 5.0.4.1 will give those people additional fixes for 5.0.4 without forcing them to pick up those schema and code reformatting changes. Additional updates to the 5.0 branch from now on will continue from 5.0.4.2 and onward.
5.2 - This will be the next major release, and will start the 4 month countdown for discontinuing the 4.4 branch. 5.2 is forked from the 5.0 branch after 5.0.6, and will contain those schema and code formatting changes from 5.0.5 and 5.0.6 in it. So if you did upgrade to 5.0.6, 5.2 will be equivalent to a point upgrade for you. Those schema changes should have caused a major release to happen anyway, so this is just fixing the numbering problem with that release (i.e. 5.0.5 should have been called 5.2 to begin with). Note that if you are using the 5.1.x development releases, those did NOT feed into this, and 5.2 would actually be a downgrade for you.
5.1.3 - The 5.1 branch is basically dead, as we’ve put all of our resources into finishing off the Harmony release (see 5.9.1 below). We’re going to encourage people on 5.1.x to move to Harmony, but you’ll want to be mindful of the release blockers first before you make the jump. There are some features in 5.1.x that were implemented differently in Harmony, and the code to migrate the related data may or may not work yet (if the feature in question is listed on the release blockers and you use it, you’ll want to wait for now). Even though this branch is dead, we’re going to put out a release with the current batch of security fixes so you aren’t left high and dry before Harmony is ready for you.
5.9.1 - This will be the first official release off the Harmony branch, and will be classified as a developer preview release, not for production use. This is what will eventually be Bugzilla 6. The code is mostly good enough to use right now, but there are still showstoppers to be able to fully release it as a production release. There are also a few gotchas when upgrading from older versions of Bugzilla. If you’re interested in helping make Bugzilla 6 happen, that list of showstoppers is here.
Immediate Help Wanted
There’s a few things (not all necessarily code related) that I would love to get help with prior to the above releases. This list is not entirely the same as the one that was in the original post to the developers list. Some of the items in that list actually got done! Yay! Thanks to those of you who pitched in!
- Documentation. This is going to be primarily for the newer branches, but the older ones are going to need some help as well. Installation instructions mostly. The examples in the docs use ancient versions of the OSes that are given as sample installs, and no sane person is going to be using an OS that old on a new install. So the installation sections of the docs need to be updated to use modern versions of the OSes in the instructions and examples. See also Bug 1785943. This has been done for the 5.0 and 5.2 branches (thanks, LCP!) but still needs to be done for 4.4 and Harmony. In fact, Harmony needs a LOT of documentation help, as what’s there now is pretty specific to trying to produce a testing environment for bugzilla.mozilla.org, rather than a standalone Bugzilla.
- Section 508 Compliance Audit. There are a number of US government agencies who use Bugzilla internally (NASA is a publicly visible example). New US government projects have to comply with the new accessibility guidelines in Section 508 of the Communications Act, so if we want them to be able to upgrade we need to comply (at least in our newer versions). See https://section508.gov/. There is a template for a compliance statement at https://www.section508.gov/sell/vpat/. I would love to get a volunteer (or a company who can sponsor someone?) who could audit the 5.2 and harmony branches for compliance, file bugs for things that are violations, and figure out how much of the VPAT we can actually provide at this point. Even if we’re not compliant yet (I suspect we aren’t) I would love to be able to provide a statement with the 5.2 release saying how compliant we are, and listing what’s left to be fixed to make us compliant. See also Bug 1785941.
Ongoing Help Wanted
There’s also a few things not specifically related to the above release that we’d love to get help with on an ongoing basis:
- Bug Triage! As you probably noticed from the lack of updates around here in a while, the bug list hasn’t been getting paid much attention to, either. Part of getting this project moving again means re-triaging the existing bug reports. Some of them are really ancient and may not even apply to the current code-base anymore. I’m going to have another blog post coming in the next day or two with information on this topic (specifics for how to help with it), so keep an eye out for that post!
- Paid Developer Time. If you are a business that makes use of Bugzilla, and has a staff person responsible for maintaining your Bugzilla installation, and that person is willing, please consider officially sponsoring that person to help with upstream Bugzilla development for at least a few hours per week. Most of our lack of development lately has happened because the last few companies that used to do that stopped providing developer time during the economic downturn a few years back (either laid off said person or pulled them away to work on other things), and they haven’t returned. The developers we have currently are all volunteer, and most of them are struggling to find time to work on it.
In Conclusion…
If you can help with any of these things, visit us on IRC or Matrix (links to both can be found in the left sidebar on https://bugzilla.org/ ), join the developer mailing list and post there, or add comments to the above-listed bugs.
--
Bugzilla Project Lead
Demo of new Bugzilla features and UX at April 3 project meeting
Our regular monthly project meeting video conference call for April will be Wednesday, April 3 at 8pm UTC / 4pm EDT / 1pm PDT. We’re getting close (relatively) with Bugzilla 6 - currently estimating end of summer or early fall, and we’ll be having some live demos of some of the recent new features and user experience improvements in Bugzilla at this month’s meeting, so you won’t want to miss it.
January Bugzilla Meeting will be January 9
Our regular meeting schedule dictates that our meetings are held on the first Wednesday of every month at 21:00 London Time. Since the first Wednesday of January is the 2nd and a lot of people will still be on vacation then (and we’ll have issues getting resources for the meeting) we’ll be holding our January meeting on January 9th instead. You can still find all the details at https://wiki.mozilla.org/Bugzilla:Meetings
The Upcoming events in the sidebar here will update to reflect that whenever WordPress’s cache expires.
Lots of Bugzilla 6 info and some questions for YOU!
Yesterday, we had our monthly project meeting, and did it panel-discussion style from the Mozilla AllHands meeting in Orlando, FL. We ended up with quite an interesting discussion with lots of good info about Bugzilla 6, and some questions for users of Bugzilla (feel free to comment here with your answers!). The recorded video is here:
Bugzilla Meeting live from Orlando
This month’s Bugzilla Project meeting coincides with the Mozilla Allhands in Orlando, and since most of our usual participants will be here in person we’ll be holding it panel-discussion style from the Europe 2 conference room on the Lobby level of the Dolphin at 4pm Eastern. Anyone who’s at the Allhands is welcome to come see us. Of course, it’ll still be streamed on Air Mozilla at 21:00 UTC as usual, and dial-in will be available for anyone remote who wants to talk or ask questions. All the details (Sched link, Video stream links, dial-in info) is at https://wiki.mozilla.org/Bugzilla:Meetings
Happy 20th birthday, Bugzilla!
The open source release of Bugzilla turns 20 years old today!
The first two paragraphs lifted from our Bugzilla history:
When mozilla.org first came online in 1998, one of the first products that was released was Bugzilla, a bug system implemented using freely available open source tools. Bugzilla was originally written in TCL by Terry Weissman for use at mozilla.org to replace the in-house system then in use at Netscape. The initial installation of Bugzilla was deployed to the public on a mozilla.org server on April 6, 1998.
After a few months of testing and fixing on a public deployment, Bugzilla was finally released as open source via anonymous CVS and available for others to use on August 26, 1998. At this point. Terry decided to port Bugzilla to Perl, with the hopes that more people would be able to contribute to it, since Perl seemed to be a more popular language. The completion of the port to Perl was announced on September 15, 1998, and committed to CVS later that night.
20 years later, Bugzilla is still alive and kicking, and about to get a major face lift that’s about 10 years overdue. I had really hoped to be announcing the release of Bugzilla 6 with this post, but we’re not quite there yet. Dylan has been making great progress with the recent merges from bugzilla.mozilla.org, though, and I’m hopeful that we’ll have something that people can at least try out in the really near future. Realistically we’re a few months away from having a full release though.
Over the last 20 years we’ve had about 300 contributors to the Bugzilla code. Here’s a few words from the very first one:
I am in complete shock and awe that Bugzilla has lasted this long. 20 years? Hardly any software lasts more than 5. I’m so very proud that it’s still going strong after these years.
20 years ago from tomorrow (on August 27th, 1998) I filed several bugs against Bugzilla, known problems that I thought would want to get fixed. I’m delighted to point out that one of these bugs <<https://bugzilla.mozilla.org/show_bug.cgi?id=540>> is STILL open. After all, you need long-living bugs if you’re going to have a long-living bug system!
– Terry Weissman
And that bug is finally about to get fixed. :-)
Other exciting developments include running as a standalone daemon with Mojolicious and the multitude of user experience enhancements by BugzillaUX in the pipeline make the future look bright!
Here’s to the next 20 years!
Watch the June 6 Bugzilla Project Meeting
- Short meeting this week because Dylan is traveling and either in an airport or on a plane right now
- Updates from Dave
- As noted at previous meetings Mozilla is downsizing and trying to find external hosting for the Bugzilla Project which they’ll still pay for, they just want to get out of the hosting business.
- Bugzilla needs to exist as a separate legal entity from the Mozilla Foundation for purposes of contracting with a hosting company, so our current status is waiting on the legal work to get done to create a Bugzilla subsidiary of Mozilla Foundation.
- The top contender for hosting right now is Linode. Other possibilities are OSUOSL and Eclipse (Emmanual reminded us of their offer)
- https://landfill.bugzilla.org/ has been closed up - static page announcing that it’s closing will be in place until the end of July. Contact Dave if you need something retrieved from it before July.
- Development updates:
- Dylan has Bugzilla mostly running in Mojolicious. https://github.com/mozilla-bteam/bmo/pull/517
- Next meeting is scheduled for July 4th. Watch for announcements on social media channels closer to that date whether it’ll happen then or not (it’s a US holiday)
June 6 Project Meeting - new URL
For those that hadn’t already seen it, Air Mozilla is in the process of switching over to a new platform. They’ve already discontinued posting new content on the old platform, and the new platform doesn’t have anonymous access available yet (but it’s coming at the end of June). This means the old URL for watching our meetings live isn’t going to work this month. Fortunately, public meetings on the new platform are mirrored to YouTube, so you’ll be able to watch it at https://www.youtube.com/watch?v=A7OC8CXMGyo
Of course, if you want to participate instead of just watch, feel free to join us using one of the methods on the wiki.
Today’s meeting will probably be short - Dylan is traveling and won’t be able to attend. The only thing currently on the agenda is an update on our hosting situation. If you have anything else you’d like to discuss, attend the meeting and ask!
See you there!