Upcoming Bugzilla Releases, and Immediate Help Wanted

Thu Aug 18 23:29:13 UTC 2022

Surprise! Bugzilla's not dead yet. :-) 

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 handoff. 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 3 or 4 months than I have in the last 5 or 6 years combined. 

I have started a new consulting business (which I'm not ready to advertise yet because I still need to do a lot of work on my website first), 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 off-list, 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 email below the release information. If you can give us a hand it would be greatly appreciated. Not all of it is code-related.] 

The Release Plans 

I would like to put out a new multi-branch release of Bugzilla sometime in the next few weeks, as soon as we can get all the pieces in place to do so. 

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.9 - I am intending this to be the final release of the 4.4 branch (barring any security issues being found in the next 4 months) as the 5.2 release below will start that 4 month countdown. 

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

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 changes from 5.0.5 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). 

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. If you're interested in helping make Bugzilla 6 happen, that list of showstoppers is here: [ https://github.com/bugzilla/harmony/blob/main/RELEASE_BLOCKERS.md | https://github.com/bugzilla/harmony/blob/main/RELEASE_BLOCKERS.md ] 

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. 

1. Get Tests Working (this one actually is code related) - the automated tests on GitHub are failing on (I think) all of the branches. They started failing without any changes to our code (this was discovered when we started trying to get caught up on patches people had submitted recently, and the patches all failed tests, and then we tried it without the patches and still failed). This is quite likely due to changes in some upstream dependency that Bugzilla uses, since our installation instructions for the test servers are all "get the most recent version of this package" as a dependency and not specific versions. If anyone has some time to spend trying to isolate this upstream dependency breakage and getting the tests fixed to deal with it appropriately, that would be a big help. This is actually the number one priority because all commits to Bugzilla are currently blocked on it. I will be working on this myself as a result, but I'd love to have a few extra sets of eyes on it. See also [ https://bugzilla.mozilla.org/show_bug.cgi?id=1785938 | https://bugzilla.mozilla.org/show_bug.cgi?id=1785938 ] 

2. 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 [ https://bugzilla.mozilla.org/show_bug.cgi?id=1785943 | https://bugzilla.mozilla.org/show_bug.cgi?id=1785943 ] 

3. 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/ | https://section508.gov/ ] . There is a template for a compliance statement at [ https://www.section508.gov/sell/vpat/ | https://www.section508.gov/sell/vpat/ ] . I would love to get a volunteer 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 [ https://bugzilla.mozilla.org/show_bug.cgi?id=1785941 | https://bugzilla.mozilla.org/show_bug.cgi?id=1785941 ] 

In Conclusion... 

If you can help with any of these things, reply to this message, or visit us on IRC or Matrix (links to both can be found in the left sidebar on [ https://bugzilla.org/ | https://bugzilla.org/ ] ) or add comments to the above-listed bugs. 

-- 
Dave Miller 
Bugzilla Project Lead 
[ https://bugzilla.org/ | https://bugzilla.org/ ] 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20220818/bd64d5bd/attachment.html>