Announcing Project Bugzilla Harmony

[Dylan Hardison]

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.

Tasks:
Some of these might even be fun.

1. Revert login_name != email (in favor of a much more general approach that we'll be making in BMO)
2. Revert multiple bug aliases (which are identical to keywords in practice)
3. Keep PSGI/Plack support -- one of the greatest features of the master branch
4. Revert the REST API in favor of the (older) system that BMO is still using.
5. Ensure a database created by 4.2, 5.0, or the master branch can be "upgraded" to from the harmony branch.
6. Move all tests to Circle CI
7. Make it easier to write selenium / web driver tests
8. Ensure all the fixes for memory leaks in BMO get ported over
10. Port GitHubAuth (this has already been done!)
11. Port MFA (two-factor authentication)
12. Port docker / containerization code
13. Change above container code to be based on Alpine instead of CentOS 6.9
14. Make bugzilla deployable to multiple cloud infrastructures.