Bugzilla Evolution Migration

[Gerardo Marin <gerardo novell com>]

DEAR SIR OR MADAM,

I WRITE YOU IN ABSOLUTE CONFIDENCE THAT YOU ARE ABLE TO RECEIVE 36,123 BUGS INADVERTENTLY ACQUIRED BY NOVELL WHEN ACQUIRED XIMIAN...

Er. On a second thought, bayesian/sa filters will junk this too fast, I were about to ask for root password in b.g.o as an initial good faith demonstration... so get serious:
 
While I took on account Christine's observations on exporting database (filter Ximian private reports, joining Connector as an Evolution component).

I'm cc'ing the bugsquad to let the whole bug team know, and attaching the initial mail,
We are a week from the proposed date for doing this migration (any weekend would be nice for me) but we need to co-ordinate with GNOME team on:

- When is this more convenient for gnome team?
- What is your preferred export (tab separated, csv, other)?
- Single big fat file with everything on it or per table file?
- Bug-buddy sync
- Open the product for business on b.g.o
- Close product for business on b.x.c
- How can I help gnome team on the whole issue?

-- 
Gerardo Marin

Novell QA Engineer

--- Begin Message ---

• From: Gerardo Marin <gerardo novell com>
• To: JP Rosevear <jpr novell com>
• Cc: Luis Villa <louie ximian com>, Christine McLellan <christine ximian com>, bugmaster gnome org
• Subject: Bugzilla Evolution Migration
• Date: Tue, 26 Oct 2004 13:20:48 -0500

Hi all,

I've been working on bugzilla migration the last few days and testing a few scripts for it.

The actual process must be tightly coordinated with b.g.o bugmasters in order to minimize service disruptions on bug reporting/triaging. A well drafted schedule needs to be done.


The sequence of steps I've seen is as follows, please add/correct any point you feel even slightly wrong.

1. Novell Ximian ops create a database dump everyday at 3:00 AM EST, the database dump is about 850 MB (360 once bzipped). This dump is somehow useless for importing the bugs themselves since it's a series of INSERT INTO table (value, value2...). Surely b.g.o bugmasters need raw data instead of SQL.

2. That dump contains the entire database, not only Evolution bugs (Q. What about Ximian products related to Evolution, still part of Bugzilla, like GtkHtml, Bonobo, Gnome-spell, etc.?).

3. MySQL version used at bugzilla.ximian.com doesn't support subqueries -actually no MySQL version I know does-, so while it's possible to create a direct data dump of bugs table, it's not possible to dump catalogs of bug reporters, duplicate bugs or attachments by using database facilities, a series of small scripts must be written to do this.

4. The easier, faster and safer way I've found to do the export I found at this point is:

- Grab the dump from b.x.c, get a local copy on my machine (it already runs a local testing bugzilla, MySQL and postgresql -which supports subqueries, making easier to export).
- Export bugs table as data instead of SQL by means of dump. (Q. Format? I found tab separated data works better than csv, since there are no tabs within bug descriptions AFAIK, but gnome bugmasters should define what's better for them).
- Export all related tables by means of scripts or postgres queries/subqueries (a short description of these scripts will follow later today).
- Create a gzipped file of all tables, deliver to gnome bugmasters where they want/need it.

  5. This process ideally must be done across a weekend (better yet, a long weekend, any in sight?) since bug reporting/triaging/fixing is minimal at that time, so we don't have to make updates by hand later in the migrated bugs (Q. Should b.x.c be closed for Evolution bugs when the process starts? We need announcements everywhere in Ximian, GNOME and Novell sites).

6. Update bug-buddy related information prior to start receiving bugs in b.g.o. so reports are pointed to b.g.o

7. No reports can be easily migrated. The ones we have are pretty hardcoded at this point (in particular those that use target milestone as a fake foreign key for Evolution related reports.) While I can send these to gnome bugmasters it will be up to them installing and modifying them to suit GNOME requirements.

8. Q. What about mail composer? It's actually assigned to  a different product (GtkHtml). Would a "composer" component be better? Are we willing to move gtkhtml to GNOME?

Comments and suggestions are appreciated.

-- 
Gerardo Marin

Novell QA Engineer

--- End Message ---