Migrating bugs from gforge bug tracker

Bug #589801 reported by mclay on 2010-06-04
12
This bug affects 2 people
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://help.launchpad.net/Bugs/ImportFormat

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://launchpad.net/trac-launchpad-migrator

There is a blog entry about the Trac migrator tool here:

    http://blog.launchpad.net/bug-tracking/launchpads-bug-import-format

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

mclay (michael-j-mclay) on 2010-06-04
description: updated
jesterKing (jesterking) wrote :

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.

Changed in blender:
assignee: nobody → jesterKing (jesterking)
importance: Undecided → Wishlist
mclay (michael-j-mclay) wrote :

The lp:blender branch is mapped to the https://svn.blender.org/svnroot/bf-blender/trunk/blender subtree off of the root of the https://svn.blender.org/svnroot subversion repository root and the lp:blender/4.x branch is mapped to https://svn.blender.org/svnroot/bf-blender/branches/blender2.4/. In the process of being mapped to bazaar, a new revision identifier use by bazaar is generated for each commit. A bazaar tag containing the "svn revno" of the subversion repository commit is also stored with each revision in the bazaar branch.

This may present a problem for bugs that reference specific subversion revino in the blender.org svn tree. Is it necessary or desirable to map the new location of the commit in the bazaar tree?

Allan LeSage (allanlesage) wrote :

Hi, is there still some interest in this?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers