Bugzilla'd version of our gnats database

[Daniel Berlin <dan at cgsoftware dot com>]

After closing some debug pr's this morning, i got bored, and seeing as how
there was a discussion about using bugzilla, i went about seeing how hard
this conversion would be.

It's not that difficult.
If anyone thinks it would be interesting, i can put the resulting bugzilla
installation up on dberlin.org.

It contains gcc bugs as of this morning.
Until I finish making it mime-decode the embedded  attachments and throw
them in the attachment database, i've cut out the actual bug
*descriptions*. I'll also make it parse audit trails into bug history.

So you have all the info (including the summary line) except the actual
text of the bug.
I expect to be done with that part sometime tomorrow.

That is, if anyone cares, and wants me to make it publicly available so
people can play with it (though please, don't start modifying bugs that
aren't going to just email you, obviously).

For those who don't care about experiences doing this, skip
the rest of the message.

As some may know, bugzilla has a script to import gnats databases.
As one would expect, it needed a bit of work.
First, It wasn't all that fast,  taking approximately *forever* to parse
some of our bugs (mainly because
it does it line by line).
It might be quicker to hand convert bugs > x meg in size, where x makes
it a reasonable number (< 50), since it'll take the script literally 5 or
10 minutes for each of these. I could only improve performance by a factor
of 2-3 here, and got it down to 3-4 minutes.
The total import time was 38 minutes to generate the sql file just a
minute ago, down from god knows how long (hours) before.

Second, it wanted to assign each component as a product, rather than as a
component of the gcc product.
Once that was fixed, i had a semi-working bugzilla.

I say semi because low and behold, people use all different things in the
release line, which is what it generates it's version list from. Or did,
anyway.

So it ended up with a list of ~2000 versions of gcc, some with funny names
like "Reading from specs file ....".

Of course, this made lynx/links have 123 pages of text on the query page.
If that wasn't fun enough, the javascript code that executes to narrow
down the lists when you select a component on the query page, took 10
minutes to narrow down the list (in konqueror. I never tried it in
mozilla).

At least, 10 minutes before i killed off the process, and went back to
work on the import script.

I changed it to search for specific releases (2.95, 2.95.2, 2.95.3, 3.0,
3.0.1, 3.0.2, 3.0.3) in the Release: line it was  parsing.  I also added a
generic extractor for the "x.x YYYYMMDD (experimental)" format that was in
there at times.  Everything else was tagged as unknown.

This seems to work fine, it gave us a nice list of versions (147).
It would probably make sense to just label all of the
experimental YYYYMMDD's of version x.x  as version "x.x pre", which i'll
do in the script.

Anyway, with that out of the way, it happily gave me the nice bug
database we have now.
It created the user accounts for anyone whose submitted a bug before, it
assigns the same bug id's so pr 3455 is still bug id 3455 (on purpose, of
course, it's not just luck).
It was actually a lot less work than i thought it would be. and the amount
necessary to make it parse the embedded attachments isn't that much more
work.
This is all just migration fun, of course.  If we are going to
even seriously  consider it, people might want to play on the test setup
i've got going, for starters. Let me know and i'll move it from my laptop
to dberlin.org.

Going from knowing almost nothing about bugzilla, to being able to setup a
server on my local computer, was trivial for the cvs version (2.15).
Compared to what i've heard and looked at for older versions, they've
greatly cleaned it up and made it easier to work with.


Just thought i'd share some notes,
Dan