Migrating bugs from gforge bug tracker
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Blender |
New
|
Wishlist
|
jesterKing |
Bug Description
The Blender project on Launchpad was abandoned by the originator. It was transfered to the current maintainer in April 2010 and is currently being used to evaluate the feasibility of using Launchpad to host the sourcecode repository and bug tracker for the Blender project. There is no advantage in moving the wiki or the mailing lists from the current locations.
While moving back to a hosted environment may seem like moving backwards, that assessment assume all project hosting sites are equal. Blender moved to a self hosted gforge site several years ago after some frustration with using Sourceforge. Many of the problems with hosting on Sourceforge do not exist on Launchpad. This experiment will examine the cost/benefit of moving to Launchpad verse upgrading the self hosted gforge site.
A barrier to migrating to Launchpad is the actual process of moving content from the Blender gforge site to Launchpad. Moving the source code repository is not an issue. The trunk is already mirrored on Launchpad and all the remaining branches could easily be migrated as well. The eventual configuration of the project on Launchpad does not require migrating from the existing Subversion repository. The mirror can continued to be used after moving the bug tracker data to Launchpad.
The problem in migrating to Launchpad is limited to migrating the data from the gforge tracker to the Launchpad tracker. The Launchpad tracker makes this a relatively painless task. The Launchpad API can read in an XML file to upload tracker content into the Launchpad tracker. The XML schema for this file format is defined here:
https:/
The only task required is to write an extraction script to pull the bug tracker data out of the gforge SQL database and building an XML file containing the content. A migration script has been written for the Trac bug tracker database. The migration script is not very complicated. It is about 1000 lines of Python. It should be relatively easy to rewrite the queries to read from the gforge postgress database.
Testinging a migration script should be relatively easy. The script developer would only need readonly access to the Blender gforge SQL database. The Trac-to-Launchpad migration tool is located here:
https:/
There is a blog entry about the Trac migrator tool here:
http://
The migration of the Blender gforge bug data to Launchpad will resole this bug. Would someone with SQL experience please volunteer for the project.
Thanks
description: | updated |
I wrote a short python script (less then 1000 lines IIRC) for porting the gforge artifacts to Redmine, and With the info about the import format I should be able to quickly adapt this.
Processing the actual database may take some while though. The copy I test with is dated a year ago, and it is already 2GB large. Since I have already worked on this before I assign this task to myself to work on. In the coming week I hope to get some first script running. Before actually committing this work to the trackers here I think I'll attach to this report examples of some tracker items for verification with others.