On 05/07/2011 18:07, Rob Weir wrote: > On Tue, Jul 5, 2011 at 12:43 PM, Pedro F. Giffuni <giffu...@tutopia.com> > wrote: >> >> --- On Tue, 7/5/11, Rob Weir <apa...@robweir.com> wrote: >> ... >> >>> >>> I'd like to explore the technical feasibility of migrating >>> to JIRA. >>> >> >> +1 >> >>> I see this page here describing the migration from JIRA's >>> perspective: >>> >>> http://www.atlassian.com/software/jira/tour/bugzilla-importer.jsp >>> >>> This appears to require db admin credentials. >>> >>> Does anyone have experience doing this kind of migration? >>> >> >> I am sure infra@ has the experience. >> > > OK. cc'ing infrastructure.
We do, for migration of bugzilla instances that use a standard data structure. The OOo modifications extend to changes in the underlying data model. The chances of that data migrating correctly are close to zero. >> I can't find it in the archives but someone in the list >> offered to make available the bugzilla archive. We should >> probably just make an experimental conversion and keep it >> if things go well. >> > > How does that help? The JIRA import feature seems to operate on the > live Bugzilla instance, or at least the live database. I can see that > doing a migration over the internet would be slow and possible prone > to time out errors. I suspect there are a variety of approaches > possible: > > Would it be unnecessarily complex to do a Bugzilla dump, import to a > temporary Apache Bugzilla instance, then import into to the real > Apache OOo JIRA instance? Advantages are if we need to redo the JIRA > conversion due to problems, we can iterate on that step much faster. > It is also an opportunity to ensure we're starting (hopefully) from > the latest stable Bugzilla rev, which may migrate easier. The live migration is a one-time deal. We can do test migrations, but once users start adding new data to the migrated instance there is no scope for going back and re-migrating the data. Things can be fixed at the database level but that is very much the exception rather than the rule. OOo is currently using a modified Bugzilla 3.2.10. 3.2.x is EOL and is no longer supported. As an absolute minimum, this would need upgrading to 3.4.x to be hosted as a live bug tracker at the ASF. If it were just used as a non-public intermediate step, no upgrade would be required. The two current ASF Bugzilla instances are using Bugzilla 4.0.0 with a very small number of local code changes and no database changes. If OOo selects Bugzilla, then the expectation is that the OOo BZ instance would be aligned to the other instances, i.e. 4.0.x with the bare minimum of local code changes. (You can modify the templates as much as you like.) As an aside, if any upgrades are required for Bugzilla (either as part of the migration or if OOo selects Bugzilla as the issue tracker) and if the OOo modifications to Bugzilla are non-trivial to apply as Bugzilla is upgraded, then the OOo community will be expected to chip in and help with the migration. Mark
