Open Bug 293028 Opened 19 years ago Updated 11 years ago

Request for phpBugTracker (phpBT) import tool

Categories

(Bugzilla :: Bug Import/Export & Moving, enhancement)

2.18
enhancement
Not set
normal

Tracking

()

People

(Reporter: wrightmf, Unassigned)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

We had several systems running phpBT and wanted to migrate to Bugzilla. Our team
wrote a perl script to perform the import. I'd like to submit this for inclusion
in contrib, after being tested for sanity.

Reproducible: Always
Adding attachment of phpbt2bugzilla perl script
What version of Bugzilla does it import into, and what version of phpBT is it
coming from?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
(In reply to comment #2)
> What version of Bugzilla does it import into, and what version of phpBT is it
> coming from?

The script worked against both phpBT 0.9.0 and 0.9.1. The import was into
Bugzilla 2.18.
OS: All → Windows XP
Hardware: All → PC
Comment on attachment 182681 [details]
phpbt2bugzilla script to import bugs from phpbt into bugzilla

Quick comments:

(1) If you can, use Bugzilla::DB or Bugzilla->dbh to connect to the Bugzilla
database. That will ensure that your connection is setup properly for any
modern version of Bugzilla.

(2) The enums (severity, priority, etc.) can change, they don't have to just be
normal, critical, etc. One problem here is that in versions after 2.19.2, the
enums aren't enums anymore, but they actually live in a table.

(3) Instead of tabs, use four spaces. You can see our style guide at
http://www.bugzilla.org/docs/developer.html, if you want.
Attachment #182681 - Flags: review-
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → 2.18
(In reply to comment #4)
> (From update of attachment 182681 [details] [edit])
> Quick comments:
> 
> (1) If you can, use Bugzilla::DB or Bugzilla->dbh to connect to the Bugzilla
> database. That will ensure that your connection is setup properly for any
> modern version of Bugzilla.
> 

Yeah, that's a great idea. This script was definitely hack-ish, but it certainly
did the job for us. If it were to be included with contrib, it would obviously
require extra work and/or regular maintenance. Would we be required to maintain it?

> (2) The enums (severity, priority, etc.) can change, they don't have to just be
> normal, critical, etc. One problem here is that in versions after 2.19.2, the
> enums aren't enums anymore, but they actually live in a table.
> 

This goes back to the maintenance issue. If it's a contrib, does it necessarily
need to be kept up-to-date with the changes in Bugzilla? Even though these live
in a table in new versions of Bugzilla, are there abstract ways to access them
that are independent of how they're stored?

> (3) Instead of tabs, use four spaces. You can see our style guide at
> http://www.bugzilla.org/docs/developer.html, if you want.
> 

That's easy enough. s/\t/    /g
Just cleaning the style up
Attachment #182681 - Attachment is obsolete: true
(In reply to comment #5)
> If it were to be included with contrib, it would 
> obviously require extra work and/or regular maintenance. Would we be required 
> to maintain it?

  Ideally, we would really like that. People do still file bugs against the
things in contrib/, and we are still sort of responsible for them. Having
somebody who can maintain it now and then is nice.

> This goes back to the maintenance issue. If it's a contrib, does it 
> necessarily need to be kept up-to-date with the changes in Bugzilla? 

  Oh, certainly. :-) If I checked it in to contrib on the tip now, it wouldn't
work with the tip. That seems a bit silly, at the least. :-)

> Even though these live
> in a table in new versions of Bugzilla, are there abstract ways to access them
> that are independent of how they're stored?

  Hrm... yeah. There's a function called get_legal_values that lives in
globals.pl in 2.19.2+, although it may move at some point in the future. The
function is called SplitEnumType in 2.18, though.
(In reply to comment #7)
> (In reply to comment #5)
> > If it were to be included with contrib, it would 
> > obviously require extra work and/or regular maintenance. Would we be required 
> > to maintain it?
> 
>   Ideally, we would really like that. People do still file bugs against the
> things in contrib/, and we are still sort of responsible for them. Having
> somebody who can maintain it now and then is nice.
> 
> > This goes back to the maintenance issue. If it's a contrib, does it 
> > necessarily need to be kept up-to-date with the changes in Bugzilla? 
> 
>   Oh, certainly. :-) If I checked it in to contrib on the tip now, it wouldn't
> work with the tip. That seems a bit silly, at the least. :-)
> 
> > Even though these live
> > in a table in new versions of Bugzilla, are there abstract ways to access them
> > that are independent of how they're stored?
> 
>   Hrm... yeah. There's a function called get_legal_values that lives in
> globals.pl in 2.19.2+, although it may move at some point in the future. The
> function is called SplitEnumType in 2.18, though.

Is there any way to gauge desirability for this script? I don't mind assisting
in its upkeep if there are people who want/need it, but it doesn't make sense
for me to put any more work into it if no one plans on using it anyway. I only
recommended it because our team looked all over for a method of extracting phpBT
bugs into bugzilla to no avail. We took matters into our own hands.
(In reply to comment #8)
> Is there any way to gauge desirability for this script? [snip]

  It's hard to say. I'm not sure how many people use phpBT, but that probably
has something to do with the fact that we don't have migration scrpit :-)

  At the worst, we put it into contrib/ and then somebody submits a patch to us
when it breaks on their local installation. :-)
I can try to implement your two suggestions (Bugzilla::DB / Bugzilla->dbh and
the enum issue) if you'd like, but it probably won't be for another week or two.
Developing the initial script was quick as I could do it on my day-job's dime.
Now that the script has done its job, any additional maintenance will be on my
own time. Currently the day-job is taking up more of my own time than usual. :)
(In reply to comment #10)
> I can try to implement your two suggestions (Bugzilla::DB / Bugzilla->dbh and
> the enum issue) if you'd like, but it probably won't be for another week or two.
> Developing the initial script was quick as I could do it on my day-job's dime.
> Now that the script has done its job, any additional maintenance will be on my
> own time. Currently the day-job is taking up more of my own time than usual. :)

  OK. I can wait a week or two. :-) It's Open Source, I understand that all our
contributors are volunteers, for the most part. :-)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: