132181 - upgrade to bugzilla 2.16 (when available)

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: General, defect)

Description

[Robert Pollak]

See http://www.mozilla.org/projects/bugzilla/status_updates/ for the current
situation regarding the 2.16 release.

Comment 1

[Tim Powell]

The status page just says that mozilla.org treats bugzilla as production
critical (as it should) but doesn't indicate how or when it will ever update
2.16. Is the plan to deploy and test it elsewhere first? I don't know if it is
practical, but making partial upgrades, such as the revised query page, could
have enormous benefits. The new query page could reduce the number of duplicates
and improve the speed of query for less experienced bugzilla users. It's also
more accessible in general.

Comment 2

[Matthew Tuck [:CodeMachine]]

The idea is that we whack on Bugzilla as much as possible (and increase our
ability to do this over time) before installing on bmo.  Then when we think it's
ready for production use, and there are no known issues, we install it on bmo. 
Then we fix any problems that finds, then we release.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Reassigning to myself and making Dawn the QA contact since I'll be doing the
upgrade.  Adding dependency on bug 140487, which is about upgrading Perl modules
on that machine.  Unsetting the target milestones, which don't really make sense
in this context, and reseting severity, which makes some sense.

In addition we need to do (at least) the following things before upgrading to 2.16:

* give people advance warning of the upgrade and make sure it doesn't conflict
with important periods of heavy bugzilla use (like release of a mozilla 1.0rc)
* give people advance warning that the buglist.cgi and show_bug.cgi HTML is
changing so they can rewrite their scripts
* work out some b.m.o-specific hacks like a "classic" format for query.cgi
* un-rot a few patches for things i want on b.m.o after the upgrade (including
98801)

Comment 4

[Bradley Baetz (:bbaetz)]

Remember to reset the param for the default query for query.cgi when you do this.

Comment 5

[Myk Melez [:myk] [@mykmelez]]

cc:ing Shiva so he knows the current plan to upgrade on Wednesday, June 5,
6:00PM PDT (UTC-08:00).

Also, adding 72837, which I want for the upgrade.

Also, assigning to myself.

Comment 6

[Myk Melez [:myk] [@mykmelez]]

Err, accepting bug (and this time for real).

Comment 7

[Matthew Tuck [:CodeMachine]]

Myk a date of June 5 is very worrying.  Past experience has shown our ability to
find bugs on other installations to be not good.  I don't see any way how we can
release 2.16 until it is on bmo.

I understand that bmo wants to have less risk from upgrades.  That is why we
have instituted release candidates tested outside of mozilla.org, and that is
why we will be moving towards a more comprehensive testing suite.

Perhaps at some stage we will be prepared to forego the bmo testing stage, but I
don't believe we are there yet.  Releasing without bmo testing is just going to
lead to many unfound bugs and drop the confidence in Bugzilla as a whole, which
won't help mozilla.org one bit.

Comment 8

[Myk Melez [:myk] [@mykmelez]]

I talked with mozilla.org staff about this issue last week.  I've been trying to
get us (the Bugzilla community) focused on releasing for weeks, but with little
success (large, risky, unnecessary changes were still blocking 2.16 last week,
and a lot of work was done to make internationalization and other post-2.16
changes easier despite those not being goals of the release).

I suggested to staff that we abandon our current plan (to wait until after the
2.16 release so we get the benefits of other installations finding regressions
before us) and upgrade this week (either to a 2.16 release or another stable
point in the development cycle if the release had too many big risky changes in it).

Staff discussed it and concluded that now was a bad time to upgrade because of
the intense activity in the Mozilla community and participating organizations
around the release of 1.0.  This is not the time to be making changes to
mozilla.org's core development and management tools.  I could probably have done
it several weeks ago when there would still have been a comfortable cushion of
time between the upgrade and the end of mozilla.org's release cycle, but I can't
do it now.

(The other factor affecting this decision is that I'm getting married May 18 and
can't do the upgrade too soon before the wedding because I won't be available to
monitor b.m.o closely for regressions.)

On the other hand, I don't think the situation is as bad as you make it out to
be.  Bugzilla 2.16 certainly has regressions and bugs, and it may have more than
its share of them given the rapid pace of development at the end of the cycle. 
We're doing a release candidate this time, however, and that's an effective way
to get the release into the hands of adventurous installations who can test and
find many regressions before we release.

No doubt b.m.o will find more, but the release candidate will bring up the
quality of the release to a level I think we'll be comfortable shipping.  And,
if that's not the case, we can always do a second release candidate instead of a
release, at which point we'll be close enough to June 5 that b.m.o will probably
upgrade to that candidate before the final release happens.

Comment 9

[Matthew Tuck [:CodeMachine]]

Bug #93667 contains rewrites to referential integrity checking which could
result in a speedup (or a slowdown even), and you might want to consider testing
them and placing them on bmo (in a second CGI) so we can compare.  However, this
could probably be done anytime, not necessarily before an upgrade.

In particular there is a double cross checking rewrite first of all, but also a
single cross checking rewrite that still needs to be attached (blocked by the
other patches).

Comment 10

[Gervase Markham [:gerv]]

Bug 133559 (replacement for Bugzilla Helper) is not an upgrade blocker, but I'd
like to see it applied as soon as the upgrade is done. Bugzilla Helper is old,
buggy and a pain to maintain. The new version is shiny, better and should cut
down on dupes.

Gerv

Comment 11

[Gervase Markham [:gerv]]

CCing self, and adding comment so I get mail which will remind me to look at
this bug and review its dependencies :-)

Gerv

Comment 12

[Myk Melez [:myk] [@mykmelez]]

Updated dependencies to remove the least important bugs from the list of blockers.

Comment 13

[Myk Melez [:myk] [@mykmelez]]

Adding the patch for implementing format support in query.cgi.

Comment 14

[Robert Pollak]

Fixed. Regressions should be collected in bug 150783.

Comment 15

[Myk Melez [:myk] [@mykmelez]]

Removing alias and dependencies that weren't met.