tl; dr I want Bugzilla 6 to basically be a portable version of the code as it exists on bugzilla.mozilla.org
So we've discussed this at the previous two Bugzilla meetings, and I've chatted with a few people about this in passing,
but to make to official I wanted to announce my intention of rebasing the next major release of Bugzilla on the current bugzilla.mozilla.org code.
There needs to be some discussion on what this means, and I don't have all that figured out just yet but I do have a general shape of
what the end result is:
1. There will be an upgrade path from the current 5.x release to this new "bmo-based" 6.0 release
2. There will be an upgrade path from the master branch to this as well
In this context, "upgrade path" means that the schema will migrate successfully.
3. This doesn't automatically mean BMOs extensions will get merged up, but we may ship them disabled. This is particularly the case when there is code that is mysql-specific
(although ideally I'd like to fix that)
There are a lot of changes I've seen in RedHat's 5.0 beta that I would love to also merge too -- but as those aren't public yet it isn't on my roadmap.
The rationale for doing this is simply there is a large amount of work going into BMO -- including multiple UX improvements (from the new enter bug page to Kohei's effort to redesign the general UI
(header/footer). There are also changes that have slipped in to Bugzilla that BMO can never support as implemented,
among these are the current implementation of user names (there is a different plan for implementing the same functionality in BMO) and the REST API rewrite.
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
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 github.com/bugzilla/bugzilla 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.