Announcing Project Bugzilla Harmony

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 stag=
nation of development against upstream.
Later you may hear more about something called Bugzilla Quantum, which is s=
et of ambitious UX changes to BMO.
This should make it even more obvious why we seek to harmonize the two code=
bases.=20

I'm not going to go into any low-level details about code, but about proces=
s.
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.=20
1.1. No requiring perl 5.14, though nothing prevents us from working *bette=
r* on modern perls.
1.2. The usernames !=3D login patch has to be backed out (someone started t=
his, 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 under=
standing 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 (f=
rom 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 branc=
h should be like.

Tasks:
Some of these might even be fun.

1. Revert login_name !=3D email (in favor of a much more general approach t=
hat 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 br=
anch
4. Revert the REST API in favor of the (older) system that BMO is still usi=
ng.
5. Ensure a database created by 4.2, 5.0, or the master branch can be "upgr=
aded" 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.



-
To view or change your list settings, click here:
<https://lists.bugzilla.org/cgi-bin/mj_wwwusr?user=3Dgcbd-developers-Uylq5CNFT+jYtjvyW6yDsg@public.gmane.org>