Announcing Project Bugzilla Harmony

[Gervase Markham]

Hi Dylan,

Thanks for this - it's good to see some progress on defining what we are
going to be doing :-)

On 30/11/17 20:36, Dylan Hardison wrote:
> 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.

What are the current Perl requirements for stable, trunk and BMO?

What is the objection to updating the version of Perl we require?

> 1.2. The usernames != login patch has to be backed out (someone started this, and I've asked gerv to review it on GitHub)

Remind us all why this needs to happen?

Have we shipped this code to anyone?

> 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

What is your goal here? What about our current development model is
broken and needs fixing? Are there specific bits of this rather long
document which you are particularly concerned we adopt?

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

I assume "harmony" will be a branch in http://github.com/bugzilla/bugzilla?

Will "harmony" start from master, stable, or from the BMO codebase?

I was rather expecting to start with the BMO code and work back towards
Bugzilla compatibility, rather than starting with master and working
towards BMO compatibility. The former certainly seems like it would be
easier to do...

> 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

I have no particular objection, but why Alpine Linux? What is that?

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

By "release process", do you mean "the process which result in the thing
we call e.g. Bugzilla 6.0"? Or are you talking about some testable
milestones we might ship along the way?

> The release notes should be exactly the commit messages. Part of reviewing a PR is making sure the commit messages tell the appropriate story.

I don't think this particular point is going to fly. It means you can't
really tell any story which spans multiple commits, and it means you
won't be picking out particular features as worth promoting. Doing
things this way will just result in pretty useless release notes. I
understand and agree with your desire to reduce the work involved in
shipping a release, but I think this is an over-economy.

> Commits / Reviews / Pull Requests:
> 
> Read the C4 document, that is what contributing to Bugzilla's harmony branch should be like.

That is a somewhat intimidating statement; see my question above. We
have been discussing a significant change to _what_ we are building; a
significant change to _how_ we are building it is somewhat of a bolt
from the blue. I would very much appreciate it if you were to explain
all this a bit more.

> 4. Revert the REST API in favor of the (older) system that BMO is still using.

Why is that necessary? Cannot a new, improved API and the old one live
in parallel?

> 5. Ensure a database created by 4.2, 5.0, or the master branch can be "upgraded" to from the harmony branch.

I think you mean the other way around :-)

> 10. Port GitHubAuth (this has already been done!)

Surely the harmony branch needs eventually to support all BMO's extensions?

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla