This page is about upgrading Bugzilla from 2.20 to 3.4. This upgrade took place in 2009.

Overview

GNOME currently runs a pretty heavily customized version of Bugzilla 2.20.5. The oldest supported version of bugzilla is 2.22, and even that will be EOLd in the near future. Let's figure out together a good way of upgrading to a supported version -- and staying up to date once that is done.

This part of the agenda was composed by Christian Reis <kiko@canonical.com>, phone number 1 612 216 4935.

Considerations

• A good solution would migrate forward all significant extensions and modifications done to GNOME's Bugzilla.
• Just moving our existing patches forward has a significant one-time cost. Because a lot of Bugzilla's design evolved into 3.0, it is not just mechanical work to adjust patches -- there's rework that will need doing.
• Moving our patches upstream (or as extensions tied to upstream hooks) has an additional -- significant -- cost. However, it's the only way to stay close to upstream releases without major suffering through every upgrade. It also requires more significant design work than porting the patches forward.

A proposal

Last year Canonical contracted Max Kanat, upstream Bugzilla developer, who worked hard with Olav to describe the set of modifications implemented. We're interested in getting GNOME running a recent version for a number of reasons, one of the most important being the inter-bugtracking facilities implemented in tip. The work Max and Olav did resulted in a long list of requirements for an upgrade. As part of this work they also divided the requirements into two parts -- one essential to running an upgraded version, and one describing features that could acceptably be ported forward after the upgraded Bugzilla instance was deployed. Let's call these parts "blocking" and "non-blocking". The non-blocking items are marked as "DELAYED" in the document sent out to participants in the call.

Canonical is interested in sponsoring part of this work. Our initial proposal is to sponsor a forward-port of the blocking patches. The next steps after that, however, require some thought.

• Forward-porting the non-blocking patches could be done by another interested party or organization, who could choose to work with Max or with another good engineer that could adequately implement the work.
• This however leaves us with no upstreaming strategy. One option is to as the blocking work is deployed, shift energy into upstreaming the patches; this will take time, but once it is done we can do another upgrade of Bugzilla to a version which supports the features and hooks we've upstreamed. This would incur in delaying the non-blocking work considerably. We'd also need to find someone interested in sponsoring or performing this work; Canonical would consider sponsoring part of this work.
• We could also choose to delay the upstreaming until after the non-blocking work is done. However, this is likely to jeopardize the upstreaming (in part because Bugzilla will move forward during that time) and Canonical is less interested in sponsoring in this option given the potential risks of much higher cost in the actual work.
• Whatever we do, it would be very good policy to set up a continuous upgrade test versus Bugzilla trunk so we get early warning of when changes upstream make our Bugzilla modifications incompatible.

Let's consider our options and figure out who has a stake in this upgrade, and what we can do make it happen.