Bugzilla:Project Proposals
This page is collecting specifications for larger projects that need to be done for the Bugzilla Project, with the goal of providing concrete plans that can be used for project planning, grant applications, and direction of developer funding by ZBC.
If you are interested in contributing towards funding any of these projects, please consider a donation to the General Project Fund.
Guidelines for this page:
- Proposal Status should remain in Draft until we're ready to work on acquiring funding.
- Before a proposal can be marked Ready:
- The text of the proposal needs to be written in a way that can be used in grant applications to grant providers who may not be familiar with Bugzilla (i.e. spell out everything, and elaborate on background info when required). We may be able to pare it down depending on who the grant provider is, but it's better to have a complete proposal that we can pare down than to have to expand on it in a rush.
- We need an Hours Estimate and a Funding Required amount. If ZBC is coordinating the acquisition of developers for a project, they currently pay $50/hr for development time (which is definitely below market rate, but the budget is really limited unless we get a lot more donations).
Bugzilla 5.2.1, 5.0.4.2, 5.3.4, 5.9.2 Releases
| Proposal Status | Ready |
| Hours Estimate | 20 |
| Funding Required | USD 1000 |
| Funding Status | Acquired |
| Funding Source | End User Donations via ZBC |
| Project Status | In Progress |
Project Description
Coordinate the release of Bugzilla 5.2.1, 5.0.4.2, 5.3.4, and 5.9.2, including the coding or review of patches that block those releases, as defined by the dependency tree on bug 1850651. It is understood that items could be added or removed from this tree as work progresses, as the suitability of the items may be reassessed as work is performed and more knowledge of those items surfaces. Any changes should be made in the best interests of the quality and security of the releases.
Bugzilla 6 Release
| Proposal Status | Ready |
| Hours Estimate | 80 |
| Funding Required | USD 4000 |
| Funding Status | Acquired |
| Funding Source | End User Donations via ZBC |
| Project Status | In Progress |
Project Description
Coordinate the release of Bugzilla 6, including the coding or review of patches that block that release, as defined by the dependency tree on bug 1538797. It is understood that items could be added or removed from this tree as work progresses, as the suitability of the items may be reassessed as work is performed and more knowledge of those items surfaces. Any changes should be made in the best interests of the quality and security of the releases.
Infrastructure Refresh
| Proposal Status | Draft |
| Hours Estimate | pending |
| Funding Required | pending |
| Funding Status | None |
| Funding Source | |
| Project Status | Not Started |
Project Description
The Bugzilla Project has two Linux servers which have outdated operating systems. Those servers host the project email and mailing lists, application update notification server, and some bots that relay information between Bugzilla, GitHub, donation sources, and our chat services. Servers with current operating systems need to be deployed, and services migrated from the old servers to the new ones.
In addition, the Landfill Test Server could use a lot of love. (Should this be its own project instead of lumping it with the server upgrades?)
- The Bugzilla Harmony installation on Landfill doesn't work. The current installation docs intend for you to run Mojolicious as a standalone server. For our sysadmin's piece of mind (and ease of managing SSL certificates) it needs to be behind an Apache reverse proxy. The current installation needs Apache <-> Mojo integration help. And we need to update the Bugzilla installation documentation to describe what gets done to fix it as this will certainly not be an uncommon installation requirement.
- It seems to get attacked by bots frequently. Cloudflare proxy doesn't play nice with older Bugzilla versions. Investigate deploying Anubis or similar to let us tune the bot detection in a way that doesn't break Bugzilla.
- The periodic data reset currently has to be done manually. Automate it.
- Autogenerate a random dataset to populate the database every time it gets reset
- Make the landing page look nicer
Funding Info
In addition to the hourly labor, this project will require additional hosting expenses during the setup and cut-over period, probably in the $5 to $50 range.
I18n Redesign
| Proposal Status | Draft |
| Hours Estimate | pending |
| Funding Required | pending |
| Funding Status | None |
| Funding Source | |
| Project Status | Not Started |
Project Description
Bugzilla currently uses a templating system which allows the page display templates as a whole to be overridden by language. This means that anyone maintaining a Bugzilla localization must also replicate any code changes made to the English templates in their localized templates, in addition to just translating the text.
The goal of this project is to extract all of the localizable strings out of the English templates and move them to a standardized localization format (such as ".po" files), to allow localizations to be crowdsourced via tools such as Pontoon or Weblate, and eliminate the need for the entire template structure to be replicated for each localization.
Bugzilla uses Template Toolkit 2 for its template engine. The following Perl modules are actively maintained and offers a way to implement GNU Gettext in Template Toolkit:
See also bug 407752.
Full GitHub Pull Request Integration
| Proposal Status | Draft |
| Hours Estimate | pending |
| Funding Required | pending |
| Funding Status | None |
| Funding Source | |
| Project Status | Not Started |
Project Description
The Bugzilla source code lives on GitHub. While we still enforce bug reporting via Bugzilla itself rather than using GitHub Issues, GitHub's Pull Request system is an invaluable tool for doing code review and landing the code once it's ready. Right now, bugzilla.mozilla.org (BMO) can utilize GitHub's webhooks to automatically link a pull request on a bug report (it treats it like an attachment on the bug) if the title of the PR references the Bug number, but this is the only integration it has.
The goal of this project proposal is to make GitHub Pull Requests be a first class citizen on a Bugzilla bug report.
- Eliminate duplicate attachments (the current system occasionally will add the same PR to the same bug more than once).
- Show the current status of a PR next to it in the attachment table, including review requests
- Add comments to bugs when things on the PR change, such as a reviewer approving or requesting changes or a new commit is pushed to the PR.
- replicate comments on the PR back to the bug.
- (this proposal is still draft - add stuff here if you have more ideas of ways to integrate a bug with GitHub)
Note: after we typed this up, we discovered that Mozilla may have just done most of this, the following landed in their tree in the last 12 hours before typing this (July 3, 2026) : Commit c69f20e: Bug 2043733 - Live Github Status for Pull Requests which created the GitHubPullRequests extension.