| Title | No migration from Perforce jobs to defect tracker |
| Status | closed |
| Priority | essential |
| Assigned user | Nick Barnes |
| Organization | Ravenbrook |
| Description | There's no way to migrate jobs from Perforce to the defect tracker. We used to have a script and instructions for doing this but it was so difficult to use and so prone to problems [GDR 2001-03-23] that we removed it from the AG. |
| Analysis | It used to be that to do this, the administrator would need to add fields to existing jobs that they want migrated, and also cause the corresponding issues to be created in the DT. We needed to supply tools to do this. This is likely to come up during the alpha test with Perforce on 2000-10-26, as they use only Perforce jobs and are expecting to be able to migrate to integrated TeamTrack use. RB 2000-10-17 In fact, it didn't come up at Perforce, but it may come up during the beta release, if anyone out there uses Perforce jobs currently. RB 2000-12-04 Fixed for TeamTrack (see fixes). Still a problem for Bugzilla. GDR 2001-02-27. See also < http://www.ravenbrook.com/project/p4dt.../2001-02-22/version-1.0-support/#job-22>.We still have migrate_teamtrack.py but it's not documented in the AG and we don't recommend that anyone use it. There are six major problems with migration from Perforce jobs to issues in a defect tracker. 1. Users with Perforce jobs may already have specialized the jobspec. Their jobspec fields need to be translated into defect tracker fields. This is very hard to handle automatically, and in fact impossible to handle in a really general way. So the user who is migrating from Perforce jobs must get involved in advanced configuration of the migration script. 2. Defect trackers usually hold much more information about each issue than is usually kept in a Perforce job. We can get around this by forcing the user to enter default values for the additional fields. Issues for which these default values are inaccurate must subsequently be corrected by hand in the defect tracker. 3. The P4DTI places requirements on the Perforce jobspec. It always needs to add some fields to it. In fact, without advanced configuration it needs to completely rewrite the jobspec. Our intention for handling this when migrating from Perforce to a defect tracker is to migrate all the jobs into the defect tracker, then delete all the jobs, then rewrite the jobspec, then replicate all the jobs back out of the defect tracker. 4. If an organization is already making serious use of Perforce jobs, we expect them to require that jobs retain their identity when the P4DTI is introduced. So job N would have to stay as job N after the P4DTI is running. We can handle this, but it's non-trivial. 5. The teamTrack API is very slow when it comes to handling large quantities of data. Migrating hundreds or thousands of jobs into teamTrack will take a long time. (this is also true in the other direction.) 6. The defect tracker may not provide a programmatic interface for creating issues. Bugzilla does not. There are two approaches for creating Bugzilla bugs: either update the database directly or talk HTTP to the Bugzilla web server. Updating the database directly is quick, but makes it hard to ensure that we are working compatibly with Bugzilla. Talking HTTP to the web server is slow. [this big piece of analysis added by NB 2001-04-19] GDR 2001-05-01: See [NB 2001-05-01a] for analysis of the problem of how to name the issues; and [NB 2001-05-01b] for some design. |
| How found | inspection |
| Evidence | <http://www.ravenbrook.com/project/p4dti/version/0.3/manual/sag/#section-6>[GDR 2001-03-23] < http://www.ravenbrook.com/project/p4dt...c/2001-03-23/release-1.0.5-test-report/>[NB 2001-05-01a] < http://info.ravenbrook.com/mail/2001/05/01/15-03-22/0.txt>[NB 2001-05-01b] < http://info.ravenbrook.com/mail/2001/05/01/15-11-48/0.txt>A customer request: < http://info.ravenbrook.com/mail/2001/04/09/23-18-22/0.txt>[NB 2001-05-10a] < http://info.ravenbrook.com/mail/2001/04/10/13-15-51/0.txt>[NB 2001-05-10b] < http://info.ravenbrook.com/mail/2001/04/10/13-18-40/0.txt>Another customer request: < http://info.ravenbrook.com/mail/2001/07/17/16-04-59/0.txt>A request from a TeamTrack customer: < http://info.ravenbrook.com/mail/2001/07/24/19-34-22/0.txt>, item 2. |
| Introduced in | 0.5.0 |
| Test procedure | <http://www.ravenbrook.com/project/p4dti/master/test/test_p4dti.py>, section 17 |
| Created by | Richard Brooksby |
| Created on | 2000-10-17 15:45:25 |
| Last modified by | Gareth Rees |
| Last modified on | 2001-12-10 18:57:21 |
| History | 2000-10-17 RB Created from comment that NB made while reading the SAG draft. 2000-12-04 RB Improved description for end users. 2001-02-27 GDR Updated Title and Description. 2001-04-19 NB Much analysis added. 2001-05-01 GDR Yet more analysis. 2001-05-10 GDR Added a customer request. 2001-07-17 GDR Added customer request and more information for support. |
| Support | Advice for releases 0.0.0 to 1.1.2 Symptom. An organization already uses Perforce jobs and wants to migrate them to the defect tracker, but can't do that. Cause. The P4DTI doesn't do this yet. See the migration design for an analysis of the difficulties. Workaround 1. Wait for the next but one release of the P4DTI, estimated for 2001-10, which will support migration from Perforce jobs to the defect tracker. Workaround 2. Enrol as a beta-tester for the migration, which we plan to take place in 2001-08. Workaround 3. Get jobs into the defect tracker in some other way. With only a few hundred jobs its probably economical for an administrative assistant to do it by cut and paste. Alternatively, one could use SQL server or MySQL to put the jobs directly into the defect tracker's database. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 24042 | closed | 2001-11-20 16:20:35 | Gareth Rees | New manual "Advanced Administrator's Guide" (AAG). Added new manual to build procedure and indexes. Renamed "pre_migrate_issue" as "translate_jobspec_advanced". |
| 23774 | open | 2001-11-05 19:40:54 | Gareth Rees | AG explains how to replicate new jobs from Perforce to the defect tracker (also first draft of migration documentation). Source matches documentation. |
| 8971 | open | 2001-02-23 12:21:49 | Gareth Rees | The migrate_teamtrack.py script now allows you to preserve jobnames. |
| 8967 | open | 2001-02-23 11:09:35 | Gareth Rees | Improving migrate_teamtrack.py |
| 8942 | open | 2001-02-22 20:41:53 | Gareth Rees | Made migrate_teamtrack.py effective; documented how to use it. |
| 5378 | open | 2000-12-04 16:54:01 | Richard Brooksby | Documented the fact that the Perforce repository should not contain any jobs. |