MigrationToBugzilla

From Develop

Revision as of 23:23, 26 November 2010 by Bdk (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

Migration To Bugzilla

This page covers the migration plan for our Trac to Bugzilla bugs data migration.


FAQ

Can we allow users to search tickets and reports without having to create an account and log in?

Yes. We can disable requirelogin.


Can we obscure email addresses when the user is not logged in?

It doesn't look like we can do that:


After we get a successful migration done, how do we disable new ticket activity in Trac?

We can also totally disable the ticket system by doing this: 

Disable the ticket components, in your TracIni:

[components]
trac.ticket.* = disabled

Better way to do this is to adjust the group/user permissions on ticket-related actions so that no one may create/edit tickets.

from the TracFaq: http://trac.edgewall.org/wiki/TracFaq#we-re-already-using-bugzilla-can-i-disable-tickets

Stage 1: disable peoples' permissions to create new tickets and change tickets.

Stage 2: disable the Trac ticket component altogether.


After we switch bug-tracking systems, what else do we have to update? Do we have a list of things that point to the Trac ticket system?

Need to add a few HTTP redirects: 

   RewriteRule /democracy/newticket http://bugzilla.pculture.org/enter_bug.cgi?product=Miro [R=permanent]
   RewriteRule /democracy/report(.*)$   http://bugzilla.pculture.org/ [R=permanent]
   RewriteRule /ticket/(.*)$ http://bugzilla.pculture.org/show_bug.cgi?id=$1  [R=permanent]


Can we have #xxx things in Trac point to Bugzilla bug urls?

I adjusted the mantis_tickets.py plugin at http://trac.edgewall.org/attachment/wiki/ChristianBoos/mantis_tickets.py to use for Bugzilla redirection.

attachment:"bugzilla_tickets.py"


Can we have rxxx things in Bugzilla point to Trac revision urls?

This can be done after the migration.

Bugzilla looks like it has a very nascent extension system. It's nascent because while they say they have hooks, there really aren't many except in the templates. It's possible we could write a Bugzilla extension that hooks into the "aftercomments" hook and creates a list of links for revisions referenced in the comment. I think this would cover longdescs, too.

This is very very lightly covered in http://www.bugzilla.org/docs/3.0/html/cust-hooks.html .

FIXME


Timeline

Will tried to do the migration Wednesday night (8/15/2007) and bumped into a few issues that caused him to revert back to the Trac ticket system. Will talked with Matt and had Matt increase the max_packet_size to something more reasonable.

Will then did the migration on Thursday during the day (8/16/2007). We bumped into a few data issues which resulted in some fixes to the script. After a couple of migration attempts we were golden and Janet started cleaning up the data.

On Monday (8/20/2007) Will disabled the Trac ticket system.

On Tuesday (8/21/2007) Will asked Matt to add a few more HTTP redirects to catch more Trac ticket system requests and redirect them to Bugzilla.


Process

  1. We change the group/user permissions in Trac so that everything is read-only. assigned to: Matt or Will
  2. We migrate bug data from Trac to Bugzilla - this takes ~5 minutes on my machine, but might take longer or shorter on whatever machine Bugzilla is being hosted on. assigned to: Matt or Will
  3. We verify that the data in Bugzilla looks good. assigned to: anyone we can get to help--the more eyes the better
  4. After we've verified that things look good, we add a redirect from the Trac new ticket page to the Bugzilla new ticket page. assigned to: Matt or Will?
  5. We go through all the new Bugzilla profiles and grants us all the correct permissions. assigned to: Matt?
  6. This can be done along-side Step 5. We update all links to the Trac ticket system to the Bugzilla ticket system. We update any documentation, web-pages, etc. that talk about Trac and tickets to talk about bugzilla and tickets. We do a blog entry with the new urls. We update any files in the repository.
  7. Check in the trac2bugzilla script into resources. Add a big README that talks about the script, how to run it, what's required, and what changes should be made because our script is pretty PCF-centric.


After the migration:


Data notes

Interesting things about the resulting Bugzilla data:

First: I did a trivial black-listed-word spam removal pass on comments and the script removes 4300 or so out of 21000 or so comments. Some of them are icky.

Second: Our keyworddefs table will be kind of biggish. This is partially due to Trac having a keyword field that has no foreign key so anyone could add anything. We'll probably want to go through the keyworddefs table and fix it up.

Third: To ease the bigness of the keyworddefs table, I've lowercased all keywords. I think this is probably ok for the majority of them, but it probably ickifies some of them, too.

Fourth: When looking through bugs, you'll discover that Janet is super-human as she became the default profile to use whenever I had a Trac "person" that I couldn't build a Bugzilla profile for. However, I did add additional text stating original owner, reporter, and author values from Trac. So the identifying information should still be there, but it's possible it's not searchable.

Fifth: Attachments migrated nicely. I had to add additional mimetypes data. I used the Python mimetypes module and it looks like it guessed pretty well for most things and everything else I assigned application/octet-stream.

Sixth: I converted our priorities into Bugzilla priorities as follows: 

       Trac    -> Bugzilla
       -------------------
       highest -> P1
       high    -> P2
       normal  -> P3
       low     -> P4
       lowest  -> P5

And actually it looks like we've had two different priority systems over the course of the Trac data, so I converted the other system like this: 

       Trac    -> Bugzilla
       -------------------
       1       -> P5
       2       -> P5
       3       -> P4
       4       -> P4
       5       -> P3
       6       -> P3
       7       -> P2
       8       -> P2
       9       -> P1
       10      -> P1

Seventh: The migration of ticket changes was non-trivial. What I ended up doing was migrating most changes, but changes to cc and components I left out because I'm not really sure we care about those; changes to owner and reporter would end up looking silly since Janet is the owner and reporter of most bugs; changes to type are hard to migrate since the type of a ticket (*bug*, *enhancement*, *task*) is sort of now the severity of the bug (*trivial*, *normal*, *major*, *enhancement* ...) but there isn't a one-to-one mapping since Trac had type and severity and it looks like we had every combination of the two. We can still see the workflow changes for bugs and we can see when comments were added, too.

If that's not good enough and we need some more information, poke me. I could always convert the changes that are hard to convert by turning them into comments or something like that.

Eighth: I wrote the script so that we can re-run the migration if we decide we need to make any changes assuming that there's no new information in the Bugzilla database.

Ninth: I create new profiles for a bunch of people. At first your passwords will be funky because I wrote a script to generate them and the crypted version of them. Also, no one has permissions to anything except the user that was created when bugzilla was installed. So after we do the migration, Matt is going to have to go through and give us all permissions to things. The list of original login names is as such: 

redacted

Scripts used

Scripts that were used are in the Git repository at http://git.participatoryculture.org/tractobugzilla/ .

Retrieved from "http://develop.participatoryculture.org/index.php/MigrationToBugzilla"
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox