Any update on importing from Bugzilla to Ondemand

[Oliver Bock]

Is it still the case that (as discussed in this question here a year and a half ago) if you want to import from Bugzilla to Jira ondemand then you need to:

1. install Jira locally,
2. migrate bugzilla to local Jira,
3. make a backup of local Jira, and then
4. import local Jira backup into Ondemand Jira?

[Wojciech Seliga · Accepted solution]

Nothing has changed.

Bugzilla importer requires direct DB access to Bugzilla DB and the connection should have low latency as the importer is really chatty.

Additionally OnDemand instances use firewalls.

So it wouldn't be practical to allow such import.

[Oliver Bock]

Thanks. I am surprised that Jira doesn't import from the Bugzilla XML export. No firewalls, no need to support multiple databases. Ah well.

[Wojciech Seliga]

that's an interesting idea (I suppose you mean here exporting list of issues - search results - into XML and then importing it to JIRA). But I cannot recall anyone else raising such request.

Rememember that thanks to direct access to Bugzilla DB, JIRA Importers Plugin can make a lot of informed decisions about field types, projects, users, etc. I suppose that XML won't include all such information.

Also according to the spec XML is not Bugzilla API, so it may be fragile to depend on it. I have no experience though wrt how stable/unstable the structure of XML has been over last years.

[Oliver Bock]

Yes, the XML button that appears at the bottom of search results. I suspect that the XML is more stable than the SQL schema. An example bug looks like this:

<bug>
<bug_id>6405</bug_id>
<creation_ts>2013-06-19 10:58:00 +1000</creation_ts>
<short_desc>Bug title...</short_desc>
<delta_ts>2013-06-19 10:58:20 +1000</delta_ts>
<reporter_accessible>1</reporter_accessible>
<cclist_accessible>1</cclist_accessible>
<classification_id>1</classification_id>
<classification>Unclassified</classification>
<product>WidgetFarm</product>
<component>UI</component>
<version>unspecified</version>
<rep_platform>PC</rep_platform>
<op_sys>Windows</op_sys>
<bug_status>NEW</bug_status>
<resolution/>
<bug_file_loc/>
<status_whiteboard/>
<keywords/>
<priority>v1.0</priority>
<bug_severity>normal</bug_severity>
<target_milestone>---</target_milestone>
<everconfirmed>1</everconfirmed>
<reporter name="Oliver Bock">oliver@nospan.org</reporter>
<assigned_to name="Oliver Bock">oliver@nospan.org</assigned_to>
<cc>jan@nospan.org</cc>
<estimated_time>0.00</estimated_time>
<remaining_time>0.00</remaining_time>
<actual_time>0.00</actual_time><cf_maxwork/>
<token>1372201487-BWhUC7xE1fOG12UXfqZrTF1McB9x4OcKe3PuV6FMuFw</token>
<comment_sort_order>oldest_to_newest</comment_sort_order>
<long_desc isprivate="0">
<commentid>13558</commentid>
<comment_count>0</comment_count>
<who name="Oliver Bock">oliver@g7.org</who>
<bug_when>2013-06-19 10:58:20 +1000</bug_when>
<thetext>The first, and in this case only, comment.</long_desc>
</bug>

For me the benefit would be that I could move the bugs from one small upcoming release over to Jira. If we like it then we would move the rest. The current situation is both a lot of work and is pretty much one way. This feels too risky for me when Bugzilla is stable and with a few more hacks to our scripts can probably do what we want.

(If Jira wanted the extra information they currently get directly from the Bugzilla database then they could provide a Bugzilla add-on to turn this core information into XML.)