After a period of silence, Bugzilla project lead Dave Miller announced that the project has been updated again.

Surprise! Bugzilla isn’t dead yet. 🙂

I posted a bunch of this on the developer mailing list a few months ago, but it’s time for more people to see it. 🙂

Bugzilla was originally developed by developer Terry Weissman in 1998 for Mozilla.org A general-purpose web-based bug tracking system and testing tool; Dave Miller became project lead in July 2001. Today Bugzilla is used by organizations such as the Mozilla Foundation, WebKit, Linux Kernel, FreeBSD, Apache, Red Hat, Eclipse, and LibreOffice.

Miller said in a blog post that he hasn’t spent much time on Bugzilla over the years; but since no one else can replace him, he only steps in to make decisions when other developers are at an impasse. Twice in the past 10 years he has tried to hand over control of the project to someone else; but each time the chosen person has found a new job and doesn’t have the time to work on Bugzilla at the same time. Now, though, something has changed in Miller’s life, allowing him to finally spend more time with Bugzilla. “I’ve probably worked on it more in the past 5 or 6 months than I have in the past 5 or 6 years combined.”

During this time, Miller has ironed out some of the infrastructure issues. The list of things that have been done includes:

• Move the test suite to GitHub Actions so it runs automatically on every commit
• Update the IRC bot to talk to the IRC server again (previously it didn’t work due to an outdated version of SSL); also update the mail parsing code in it to handle new versions of Bugzilla (most importantly bugzilla.mozilla.org, whose notification emails are from issued here).
• Set up a private Git repository for secure commits so they can be staged before release and avoid early exposure.

In terms of release plan, Miller hopes to release a new multi-branch version of Bugzilla as soon as possible, which is expected to be at the end of December this year or mid-January next year. Currently, Bugzilla still supports version 4.4, which was first released in 2013. The rationale is that its support policy states that 4.4 must be supported for an additional 4 months after continuing to iterate through two new major versions before its end of life. “The next major release after 4.4 is 5.0; there haven’t been any major releases after that, which means the 4-month countdown hasn’t started yet.”

According to Miller’s plan, 4.4.14 will be the final version of the 4.4 branch. Then there’s 5.0.4.1, 5.2 which will be the next major release, and a “basically dead” 5.1 branch. After the 5.2 version is released, the 4.4 version can start the 4-month countdown to the end of the life cycle. There is also a 5.9.1 branch – code-named Harmony, which is currently in developer preview and will eventually become Bugzilla 6.

Miller explained that the emergence of 5.0.4.1 stems from a mistake by Bugzilla team members: the 5.05 and 5.06 versions released in early 2019 contained a large number of architectural changes and reformatted almost all Perl code in the source code, which violated the project support policy. . Many users noticed this lapse and chose to stay with the old version instead of upgrading to 5.0.5 or 5.0.6 which did not contain any security fixes. So 5.0.4.1 will provide those people with additional fixes from 5.0.4.

While 5.2 is forked from the 5.0 branch after 5.0.6, it will contain those schema and code formatting changes from 5.0.5 and 5.0.6. “5.0.5 should have been called 5.2 in the first place,” Miller said.

It is worth mentioning that, in view of the fact that there are other similar software to choose from, and the Perl language is less popular, Bugzilla’s way to find contributors is not easy. A developer on Hacker News said, “Bugzilla was written in Tcl and then rewritten in Perl because they realized that this would make it easier for people to contribute to it. For the same reason, the same the problem reappears; today, the fact that it’s written in Perl is as much of a liability as it was an advantage around 2000. I like Bugzilla…however, I can’t really expect or Straightforward recommendation for anyone to deploy or work on, considering it’s a foreign codebase written in Perl, even I wouldn’t want to do it myself.”

Miller hopes to have some volunteers to help with documentation, compliance audits and bug fixes in Bugzilla itself, and also urges businesses that use Bugzilla to consider offering some paid development time. “If you are a business using Bugzilla and have an employee responsible for maintaining your Bugzilla installation; if that employee is willing, please consider formally sponsoring that employee’s Bugzilla upstream development for at least a few hours per week.”

Related Reading: