Re-Starting Bugzilla development

Hi everyone!=20

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 cha=
tted with a few people about this in passing,
but to make to official I wanted to announce my intention of rebasing the n=
ext 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=20
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 successf=
ully.
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 goin=
g into BMO -- including multiple UX improvements (from the new enter bug pa=
ge to Kohei's effort to redesign the general UI
(header/footer). There are also changes that have slipped in to Bugzilla th=
at BMO can never support as implemented,
among these are the current implementation of user names (there is a differ=
ent plan for implementing the same functionality in BMO) and the REST API r=
ewrite.






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