Can Launchpad migrate projects from tigris.org?

Asked by Zearin on 2008-08-07

Tigris.org is another open source community. Among other things, it's home to Subversion.

It has a worthy mission, but I can't stand its interface. And its Issue Tracker, while functional and thorough, is not nearly as usable as Launchpad's.

So, I was wondering if it's possible to migrate projects from Tigris to Launchpad. The most important things to migrate would be the code (obviously) and the Issue Tracker (which I believe contains both Bugs and Blueprints, in Launchpad's terms).

Even if the conversion is something like 90% instead of 100% (for example, if Tigris' Issue Tracker has two fields for different kinds of data that would become one field after migration) I would very much like to know!

Thanks!

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
Graham Binns Edit question
Last query:
2008-10-06
Last reply:
2008-10-09
Christian Reis (kiko) said : #1

I don't believe we currently support the Tigris.org bugtracker. Do you know if it's a tool built specifically for Tigris, or if it derives from an existing bugtracker or open source hosting facility?

Zearin (zearin) said : #2

After some poking around, I came up with the following:

“About Issue Tracker
The Issue Tracker used on this site is a variant of BugZilla. The Issue Tracker is a more generalized tool for tracking different kinds of activities. Issue Tracker classifies issues into several types:

Defects (a.k.a. "bugs")
Enhancements
Features
Tasks
Patches
Each project that uses Issue Tracker has its own issues database. For open source projects, all registered users may query, view, and report issues. Proprietary projects limit access to project members.

Project members have additional permissions within the Issue Tracker to modify and reassign issues, as well as generate reports. Project members are also notified automatically by email whenever issues are assigned to them or there is activity on issues affecting their work.

Use Issue Tracker to entering the tasks you plan to work on. By maintaining your tasks in a database, you can avoid duplicating effort and offer feedback and help to other project members.”

More details are available at the following URL (where the above quote is from):
http://www.tigris.org/scdocs/ProjectIssues#aboutIZ

Zearin (zearin) said : #3

Um, so… Anybody look into this yet?

Graham Binns (gmb) said : #4

Sadly, I haven't had time to look into this over the past cycle. I'll look into it this coming week and get back to you.

Is there a specific project you're looking to migrate?

Zearin (zearin) said : #5

Yes! I'm interested in migrating ArgoUML (http://argouml.tigris.org). I've already created a project for it on Launchpad (https://launchpad.net/argouml).

NOTE: I'm not the lead for ArgoUML. However, I think the project would benefit hugely from migrating to Launchpad, so that's why I opened this Question. I had to make sure it's possible to migrate at all before I carefully suggest the idea to the ArgoUML devs.

If they say no, then I will just mirror what I can on Launchpad. If they say yes, then the fun begins! Obviously, a yes will be much more likely if the migration gets all Bugs (and bugs that will become Blueprints) moved.

Francis J. Lacoste (flacoste) said : #6

Tigris seems to use a CollabNet installation. We don't have an importer or even support linking bug watches to it.

We do have an XML format from which we could import bugs, but that would necessitate that you have a dump of the bug database that you can format in that one.

To improve the ArgoUML project, you might want to request a Code Import. That will make sure that the bzr branch associated to the project is synced with the remote subversion server. You can request a code import by going to the 'Code' tab and clicking 'Import your project'.

Note that we don't have any support for migrating other stuff than Code or Bugs (so no direct import to Blueprints, nor Answers, nor project announcements).

Zearin (zearin) said : #7

Okay. This is great news!

Some wrap-up questions before I pitch this to the ArgoUML dev team:

• How long would a migration take?
• If we wanted to make use of Translations, are there any recommended methods for moving from a traditionally-localized setup to LP Translations? (I understand the only officially supported migration items are Code and Bugs.)
• If the team is reluctant to leave Subversion for Bazaar, is there a quick list of incentives for switching? (Especially special integration that Launchpad offers Bazaar projects?)

Joey Stanford (joey) said : #8

Hi,

• How long would a migration take?

Up to a few days on our end to ensure the migration script works ok with your dump. What we could do is test the dump and then set a date to migrate at which point you provide us with a new dump and we can import it hopefully the next day.

• If we wanted to make use of Translations, are there any recommended methods for moving from a traditionally-localized setup to LP Translations? (I understand the only officially supported migration items are Code and Bugs.)

I'll pass this on to our translation team as they will have better insight into this than I do.

• If the team is reluctant to leave Subversion for Bazaar, is there a quick list of incentives for switching? (Especially special integration that Launchpad offers Bazaar projects?)

See https://edge.launchpad.net/+tour/branch-hosting-tracking and http://bazaar-vcs.org/BzrWhy

Joey Stanford (joey) said : #9

From our translation gurus:

Launchpad supports the import of gettext-style template and data files.
The easiest way to migrate your translations to Launchpad is to put all
your translation templates (*.pot) and all your translation data files
(*.po) into a tarball (*.tar.gz) and upload that using the "Upload
translations" option on the translations page. To make sure your
translations are imported with as little manual intervention as
possible, please make sure the content of the tarball has the following
structure:

For the structure, we recommend making sure that each template is in a directory of its own, and has a file name with only lower-case ASCII letters. Each translation should be in the same directory as its template, and its name should be XX.po where XX is the translation's ISO-639 language code.

For the language code, use 2-letter codes where available (de, ru, pt etc.), or the 3-letter codes where no 2-letter code exists. Do not include country codes except where they're really needed. The only common cases where they are needed are: pt_BR for Brazilian Portuguese, zh_CN and zh_TW for Simplified and Traditional Chinese, respectively; and en_GB for UK English. There is also some limited support for variants ("sr@Latn").

Zearin (zearin) said : #10

Had to devote my attention to schoolwork lately, but I'm very happy with the situation and I plan on writing the request to the ArgoUML team in the near future.

Thanks!

Edwin Grubbs (edwin-grubbs) said : #11

Hi Zearin,

It appears you are happy with the answers you received. I'm going to mark this question as solved.

Cheers,
Edwin