Closed Bug 103885 Opened 23 years ago Closed 23 years ago

upgrade bugzilla installation on


( :: General, defect)

Not set





(Reporter: myk, Assigned: myk)



(Whiteboard: [Tentatively scheduled for: Wednesday, November 7])


(4 files)

The Bugzilla installation on should be upgraded to the tip
to pick up the latest fixes and enhancements.
Depends on: 98602, 99716
Depends on: 97469
Whats the timeframe on this?

Bug 101166 should really be fixed before the security group stuff happens,
otherwise people not in the group won't know that its a bug they shouldn't be
talking about in public.
The timeframe is anywhere from one week from today (Tuesday, October 16) to one
month from today (Friday, November 9), with earlier dates being preferred over
later ones.
Nominating bug 83058: need a way to hide resolved bugs in dependency tree view
The latest patch there is ready for checkin, I think (just missing a second
Nominating bug 75778: Add Windows XP to OS list
For reference, here's the twin: 
bug 92763: Add WinXP as OS selection for entering/searching bugs
Nominating bug 92676: Need summary table of bug counts
This is so high-reward that it is worth a little effort to make it available on
b.m.o asap.
Nominating bug 12284: let me specify which columns to display in a bug list
The minimum that should be done before the upgrade is to change buglist.cgi so
that it accepts an explicit columnlist parameter. A patch for this is available
in attachment 52900 [details] [diff] [review].
Here's a thought: what if we do mysql upgrade same time this happens? (bug 
Depends on: 77335
Nominating the keywords-update patch in attachment 52903 [details] [diff] [review]. Patches like this
won't be necessary any more as soon as bug 72837 is fixed.
Since b.m.o is also used for project planning and tracking, 
bug 81642 ["Split bug / Clone bug": Enter new bug with prefilled fields] 
may be worth looking at. That bug already has a patch that "works for me". It's
not a stopper, but it would be nice if it was looked at soon.
Nominating bug 100490, attachment 50313 [details] [diff] [review]: It's a short-term error message fix for
those who try to use QuickSearch on the b.m.o front page, but have JS disabled.
Nominating bug 102618: quicksearch should support "changed in the last n days"
That bug has been reported by someone working on mozilla, and there is a fix
Bug 101166: I'd like to see this get in before the upgrade, but I'm reluctant to
make it a blocker when there doesn't seem to be any action on it.

Bug 83058: People are using tracking bugs more often nowadays on b.m.o., and
this would make their lives easier, so it would be useful to have this.  Making
it a blocker.
Bug 75778: Unrelated to the upgrade.  When this bug is fixed the change will
take place on b.m.o. immediately.  Twin bug 92763 is also unrelated to the
upgrade since it only affects new installations of Bugzilla.

Bug 92676: There seems to be some disagreement in the bug about how/when to do this.

Bug 12284: Simple patch, looks good.  Not making it a blocker, but adding it to
the list of patches up for review in the topic line of the #mozwebtools channel,
from which I expect it to be quickly reviewed and checked-in.

keywords patch: Will be done along with the upgrade.

Bug 77335: not a bad idea.  How long is the mysql upgrade likely to take?  I
need access to the mysql server during parts of the Bugzilla upgrade process (in
the beginning to back up the database and later on to implement any necessary
schema changes and recreate the shadow database), so we probably have to do one
upgrade after the other unless the mysql upgrade can take place during the
Bugzilla cvs update/conflict resolution, which does not require mysql access.
Depends on: 83058
mysql upgrade shouldn't take more than 10-15 minutes. We probably can shut down 
mysqld right after the backup has finished and then bring it up with new 
Before upgrading to 3.23.x we have to make sure that some changes in SQL
functionalities won't break bugzilla. Those of you who are familiar with SQL
within bugzilla should go to following URL:

3.23.x can still support old ISAM table types and we can do necessary isamchk
operations but someone else have to check the SQL compatibility issues.

Nominating bug 95722: [RFE] Separate queries and buglists
A possible fix (3 lines) is available in attachment 46610 [details] [diff] [review]. It adds a link to
buglist.cgi that generates a static list.
Also, it would be great if QuickSearch could be made to work from the footer.
There are two parts to this:
1. Change quicksearch.js so that the user input is explicitly passed to the JS
function, and update the index.html page accordingly.
2. Change the footer to call QuickSearch().

The first part was originally filed as
bug 76484: Allow multiple QuickSearch forms in a single document
and a patch for it is available in 
bug 37339: Bugzilla sidebar, containing info in footer (attachment 40917 [details] [diff] [review]).

An alternative patch for both parts is available in
bug 102691: Quicksearch enhancements (attachment 51690 [details] [diff] [review] and attachment 51691 [details] [diff] [review]).

Meanwhile, another request for this has been filed:
bug 101515: QuickSearch: page footer's 'find' should allow searching
Finally, you may already have discovered that I've been partly (mis)using this
bug to submit my RFAs ("requests for attention" ;-). To avoid this in the
future, we need better way to track requests (for review) as soon as possible.

Therefore, I'm nominating bug 98801 ("request tracker") as a blocker.
afranke: proposals for review requests

a) or similar
b) Use /topic on #mozwebtools :-)

File bug?
Depends on: 103568
Depends on: 91486
oops. removing dependencies and nominating the appropriate way. bug 91486 and
bug 103568 would be really good to get in the next update. bug 91486 already has
a patch, but bug 103568 does not.
No longer depends on: 91486, 103568
Bug 81642:  As mentioned before, not a blocker.
Bug 100490: Already fixed.
Bug 102618: Not a blocker, because a simple workaround exists.
Bug 95722:  Looks cool, not a blocker.
QuickSearch (bugs 76484, 37339, 102691, 101515):
            Too many bugs.  See note below about limiting nominations.
Bug 98801:  I'd like to see this make the upgrade, but it may
            require more baking than we have time for in this
            installation cycle.
Bug 91486:  Already fixed.
Bug 103568: There does not seem to be any action on this one.

>Finally, you may already have discovered that I've been partly (mis)using this
>bug to submit my RFAs ("requests for attention" ;-).

Yes, I have discovered that.  Stop it.  Misusing this bug in the way 
you describe has no positive impact on your nominations and a negative
impact on your reputation, which in the long run has a negative impact
on your influence in the project.

Use the IRC channel and newsgroup to advocate for bug fixes you care about.
Nominate bugs as blockers for the upgrade only if their effects are severe
and debilitating or their enhancements significantly increase usability
*and* they have good fixes that are almost ready to go.

Bug #83033 is very annoying and has a patch waiting for second review. 
Apparently bug #97966 will be in soon after that.  These two bugs would be
really nice to have in the next update, they constantly annoy me.
nominating bug 63051 (no patch). This one looks pretty easy and would benefit
project management type queries at bmo in a big way.
I nominate bug 104652. This is dataloss on the dependency tree screen. We need
to track this down and work out why it's happening.

myk, we need bug 99519 checked in before mysql is updated to 3.23. Our code is
broken, it just happens to work in 3.22 because of a bug/misoptimisation.
Without this people changing a bug without adding comments won't cause mail to
be sent.

The reporter of that bug mentions that it was present in 2.12, as well, so its
been there for a long time. Would it be better to upgrade b.m.o before upgrading
mysql, just to help separate this sort of stuff? (Or do it the other way
arround, applying bug 99519's patch by hand first)

(BTW, I presume that the mysql table type will be updated too. That will help
speed, I believe, but then you won't be able to go back to 3.22 easily.)
No longer depends on: 77335
Depends on: 99519
bug 83033 - Annoying, but not a blocker.
bug 97966 - Annoying, but not a blocker.
bug 63051 - Under discussion and reconsideration.
bug 104652 - Annoying, but not a blocker.
bug 99519 - Blocker because of the severity of the bug (it causes email not to
get sent when it should).
Ok, tentative plans are to upgrade on Wednesday, November 7.  Any problems with
this date?
Yes, why are we waiting so long?  :)  We're targetting feature freeze for 2.16
on November 16, and there's features on the tip we're still waiting for b.m.o to
pick up that will make triage ever so much easier.

I heard a rumor you might not be doing the MySQL upgrade at the same time.  If
that's true, bug 99519 won't matter (yet), because it only affects MySQL 3.23.x.
Please let us know by 10/31/01 if our attendance is required for mysqld upgrade 
and what time that is needed (if the upgrade is 11/7).
Depends on: 107718

bug 107718 - mass changes give all changed bugs the groupset of the first bug in
the list. This has happened at least twice with mass changes (I just remarked
two bugs which were accidentally removed as part of the nsbeta1 keyword shuffle
(bug 105705 and bug 102798), and I saw this last with a mass qa contact change)
when ckritzer left, and I was cc'd on one of the bugs.

bug 106377 - fixes up processmail rescanall so that it can be used to fix mails
not being sent, and be run nightly so that we can hopefully track this down.

Oh, and bug 101166 would be nice, too, but its not urgent. Having it moved up in
the review queue would be nice though, since it avoids confusing UI wrt what
group a bug is in
No longer depends on: 107718
readding justdave's dependency dropped due to bug 73502.
Depends on: 107718
>Yes, why are we waiting so long?  :)  We're targetting feature freeze for 2.16
>on November 16, and there's features on the tip we're still waiting for b.m.o
>to pick up that will make triage ever so much easier.

The two primary reasons for waiting until then are that IC has time to upgrade
the mysql server and I have time after the upgrades to fix any problems that arise.

>I heard a rumor you might not be doing the MySQL upgrade at the same time.  If
>that's true, bug 99519 won't matter (yet), because it only affects MySQL 

I was considering doing the upgrades separately, but I changed my mind after
reviewing the list of 3.22->3.23 upgrade issues on the MySQL web site and
realized that there are no issues on that list that I expect to be mistaken for
Bugzilla upgrade issues.

>Please let us know by 10/31/01 if our attendance is required for mysqld upgrade 
>and what time that is needed (if the upgrade is 11/7).

Yes, your attendance is required for the mysqld upgrade.  Let's start at 7pm. 
With the mysqld upgrade being the first step.


bug 107718 - dataloss and possible security issue, making a blocker.
bug 106377 - valuable but not a blocker.
bug 101166 - nice but not a blocker.

Also, remember that to nominate a bug for blocker status do not add it to the
list of this bug's dependencies but rather post a comment about it in this bug.
 I'll review all blocker nominations and add the appropriate bugs to the
dependency list.
As part of bug 107672, two lines for detecting Windows XP were added, but
because of bug 92763 there were commented out.  I'd recommend uncommenting them
at b.m.o being that "Windows XP" was added to localconfig as part of bug 75778.
Nominating bug 108385 as an important security bug which needs to be fixed.
Adding bug 108516 to the nomination list...
Whiteboard: [Tentatively scheduled for: Wednesday, November 7]
Blocks: 75778
bug 108385: already fixed
bug 108516: already fixed

Jake, is it useful to uncomment those lines before bug 92763 lands?
No longer blocks: 75778
Uncommenting those WinXP lines will allow Windows XP to automatically be
detected at sooner than waiting for it
to be done as part of bug 92763.  The hold-up with 92763 is that because of bug
106993 having the detection return an operating system that doesn't exist in the
bugzilla install causes bad things to happen.  This won't be the case at b.m.o
because "Windows XP" will exist as a valid operating system.
Bug 107718 just got reopened...  MySQL < 3.23.5 can't handle the SQL that was
included in that patch.  Since b.m.o is getting a newer version of MySQL, that
shouldn't affect the b.m.o upgrade *IF* the MySQL upgrade is successful.  If the
MySQL upgrade is not successful, you will need to back out the patch on bug
107718 before putting Bugzilla live again.
Adding dependencies on recently discovered security holes.
Depends on: 108821, 108822
Adding dependency on yet another recently discovered security hole.
Depends on: 108812
bug 99519 - The latest patch has been marked "needs work", perhaps accidentally
according to Dave, but Jake is not around to defend it, so waving this off.

bug 107718 - Unblocking pending successful MySQL upgrade.

bug 108812, bug 108821, bug 108822 - All have two reviews and are only awaiting

bug 99608 - Not a blocker, but because it is a security issue I will apply the
patch for it when one becomes available.

This leaves no blockers for the upgrade, so full steam ahead.
No longer depends on: 99519, 107718
Myk - bug 99519 needs to be fixed, if mysql is being upgraded. Otherwise mail
won't be send, and midairs won't be triggered in certain, not very rare, cases.
Upgrade procedure:

1. Shut down Bugzilla with message:

  Bugzilla is down until 10:00pm PST for a system upgrade.

2. Run "before the upgrade" test queries.

3. Back up the bugs database.

4. Upgrade MySQL.

5. Run "after the upgrade" test queries and compare their results to the
previous set.

6. Convert database tables to MyISAM.

7. Run "after the conversion" test queries and compare their results to the
previous set.

8. Back up the /opt/webtools/bugzilla directory.

9. Reverse patches that were applied since the last upgrade and were also
checked in to CVS.

10. Call to upgrade to the latest version in CVS, and resolve
merge conflicts.

11. Run Bugzilla tests.

12. Run to catch any schema changes.

13. Make executable.

14. Turn Bugzilla back on and test.

also, additional vars will need to be set in, this should be 
addded to the procedure
b.m.o. has been upgraded.  Resolving this bug fixed.  Post-mortems to follow
Attached file upgrade announcement
This is the announcement I made to various n.p.m. newsgroups and some internal
Netscape mailing lists about the upgrade.
Attached file post-mortem
This is the post-mortem for the upgrade describing what went right, what went
wrong, and what to do better next time.
Upgrade complete.  Resolving fixed.
Closed: 23 years ago
Resolution: --- → FIXED
Component: Bugzilla: Other b.m.o Issues → General
Product: →
You need to log in before you can comment on or make changes to this bug.