Re-Starting Bugzilla development

Gervase Markham gerv at
Fri Jul 7 09:06:53 UTC 2017

Thank you, Dylan, for announcing this. As co-assistant project lead, I
also believe it's the right way to go to give Bugzilla a healthy future.
The world has changed; Bugzilla is now most suitable for organizations
which have outgrown Github Issues and similar, and in that case the more
"enterprise"-y features of BMO are appropriate. Rebasing on the living
and developed BMO codebase, and making sure the two stay close in the
future, seems like the best way of making sure upstream development does
not stagnate.

There are clearly a few things to be worked out about how to implement
this plan, and how we can get most quickly to a release. I hope we can
have a good discussion about how Dylan's goals might be best achieved.

One thing we need to do is make a list of changes to trunk which are not
in BMO. This is non-trivial as BMO is technically based on 4.4 but has
merged a great deal of code from 5.0 and master. We will then need to
work out how we intend to deal with each of those changes - merge it,
abandon it, rewrite it or whatever, and whether we do this before or
after the first release on the new path.

We also need to figure out the best source control architecture. It is
my view that this plan will succeed and Bugzilla will thrive if it is
just as easy for Mozilla devs to work on Bugzilla as it is on BMO. If
additional effort is needed to "upstream" stuff, that won't happen, the
two will diverge, and we'll end up in the same position again.

So we need to get to a position where the Bugzilla master branch is what
BMO ships from weekly. Every so often we can cut a release from there
and stabilise and ship it. How we get to the position of the BMO
codebase being the master branch remains to be worked out. I guess the
start is to import BMO into as a branch
that BMO ships from. Then we can start merging stuff into it with
Dylan's review. Once we have all that is slated for the first release,
we can cut a branch off that and ship. At that point, we can probably
"overwrite" our current master with the current BMO codebase branch, and
work from there.

dev-apps-bugzilla mailing list
dev-apps-bugzilla at

More information about the developers mailing list