Skip to content

Instantly share code, notes, and snippets.

@dylanwh

dylanwh/harmony.md

Created December 18, 2017 18:50
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dylanwh/dc345ac5dcbd71b8109fe6cbc203ad89 to your computer and use it in GitHub Desktop.
Save dylanwh/dc345ac5dcbd71b8109fe6cbc203ad89 to your computer and use it in GitHub Desktop.
Download ZIP
Bugzilla Project Harmony
Raw
harmony.md

This is my long-planned plan for improving the Bugzilla project; Bugzilla Harmony is a boring thing that we've got to do to reverse the stagnation of development against upstream. Later you may hear more about something called Bugzilla Quantum, which is set of ambitious UX changes to BMO. This should make it even more obvious why we seek to harmonize the two codebases.

I'm not going to go into any low-level details about code, but about process. I hope that I can get many people to make very small contributions towards this goal.

Goal: Harmonize the upstream Bugzilla code to track bugzilla.mozilla.org

Requirements:

  1. Significant changes to BMO must not be required. 1.1. No requiring perl 5.14, though nothing prevents us from working better on modern perls. 1.2. The usernames != login patch has to be backed out (someone started this, and I've asked gerv to review it on GitHub) 1.3. An exception to this rule is for SQL queries that only work on MySQL; BMO will change as is required to support all our supported backends.
  2. We are going to follow https://rfc.zeromq.org/spec:42/C4/ with the understanding that "Platform issue tracker" refers to bugzilla.mozilla.org
  3. All this work will happen to the "harmony" branch, and we'll continue to not touch 'master' to not break anyone that happens to be using it.

Packaging / Release:

We are not in the business of packaging, there are too many combinations to worry about all of them. People are welcome to help with packaging Bugzilla 6 / Harmony on anything, and nothing drastic will change there. But as for releasable products, there are two channels that we must support:

  1. A runnable docker container, based on Alpine linux
  2. A checkout from a tagged commit from GitHub.

The release process for Bugzilla Harmony will amount to tagging a commit (from the Harmony branch, more on that later). The release notes should be exactly the commit messages. Part of reviewing a PR is making sure the commit messages tell the appropriate story.

Commits / Reviews / Pull Requests:

Read the C4 document, that is what contributing to Bugzilla's harmony branch should be like.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment