Bugzilla 2.18 Release Timing

Normally, we test a Bugzilla release by upgrading bugzilla.mozilla.org to the release candidate. However, there is concern that we don’t want to have extended Bugzilla downtime (which is always a risk when doing an upgrade) while trying to release Firefox and Thunderbird 1.0.

On the other hand, we’ve been trying to release Bugzilla 2.18 for the past six months, and we don’t want another two months of delay (a month to Firefox 1.0 and then a month recovering and dealing with other related crises) now that we are so close.

So do we:

  • Upgrade anyway and hope we don’t break anything too badly?
  • Don’t upgrade, wait until after 1.0, and have a delayed 2.18?
  • Release anyway, and let other sites find the bugs?

Answers on a postcard…

10 thoughts on “Bugzilla 2.18 Release Timing

  1. Doron’s idea is good! Otherwise I would take the 1st solution. Since you’ve been testing it for the past 6 month, it wouldn’t be too risky…

  2. I’d go with “release anyway”. I mean, the new code has been tested, right (even if not in a “production environment”?

    If you don’t want to release it for everyone, maybe you could ask a particular site that uses bugzilla to use the new code and see if they have problems?

  3. If feasible, Doron’s idea seems the best. Otherwise, I’d stick with the second option; delayed releases suck, but breaking stuff (especially right in the middle of the Firefox 1.0 push) would be worse.

  4. We’ve already done a test upgrade – the migration worked fine. But that’s not the only thing that could go wrong. There’s no substitute for having thousands of people using the product a) all at once (scalability) and b) using every feature (testing).

  5. Been trying to post this all day and the comments were broke on here… Gerv already summarized it in the previous comment (I mailed it to him earlier), but here’s what I was going to say anwyay:

    FWIW, I already did a test upgrade on a backup copy of bugzilla.mozilla.org’s database. Downtime was under 6 minutes. However, there’s nothing we’d be able to obviously detect without having thousands of users playing with it, and there ARE schema changes, so we can’t have both open to the public at once and keep them in sync…

  6. I agree with Peter, Firefox 1.0 developement is more important than a delayed release.

    A problem that delays the 1.0 release would be an unfortunate parenthesis in Firefox history.

  7. Does b.m.o *have* to run the latest Bugzilla? If not, then smaller sites (such as mine) can be the crash test dummies for the release version.

  8. Personally, I’d love to have some of the new stuff from the newest Bugzilla. Some of the fixes would be extremely helpful to productivity, so I’m all for upgrading it. Unless Bugzilla code went almost completely unmanaged since the last upgrade, I have no doubt that most users won’t really notice much difference.