[Request] Staging import of bug data for project Ares

Hi there.

This is a very clean export, but there's still a small
problem. Several <sender> and <reporter> tags have empty email
attributes. These must be specified with a valid email address, or
left out entirely.

I believe the schema is incorrect, so I apologise for that. I'll file
a bug for it.

Gavin.

Fwiw, I can fix the data for now, but perhaps you can update your
export script, or let me know which script you're using so I can
arrange for it to be fixed.

Hi, I'm glad to hear it's mostly looking good. The export script is a Mantis plugin I've written, I'll fix it up to drop the email attribute if the address is empty. We may have once not required a mail address, that's the only explanation I have for why they're empty.

Could you name me an example or two so I can check if the new export fixes it?
This is going to take only a few minutes, are you going to be around for a little longer? And/or are you on Freenode?

Please try http://bugs.renegadeprojects.com/uploads/Ares-LaunchPad-Import-20111108-180909.xml - the empty email attributes should all be dropped. (At least the code mandates that and diff and grep don't find any left. ;) )

Oh, I am a muppet. The email address *must* be provided. I'm not quite
sure how I got the impression that not having an email address would
be fine.

If that's really going to block you we might be able to modify the
import script to allow email-less users, but there may be good reasons
to keep it this way.

Probably the quickest thing to do, if you really don't have email
addresses for these users is to create addresses for them.

By the way, I have prepared an updated schema that should get into
Launchpad soon that would have saved you this toing and froing:

  lp:~allenap/launchpad/bug-export-schema

Gavin.

Also, if you want to chat you can get me in #launchpad on freenode.

I have reverted to the previous version of the script, filled in the missing addresses via DB and validated against both the old and the new schema.

http://bugs.renegadeprojects.com/uploads/Ares-LaunchPad-Import-20111109-174022.xml is the current file.

1515 bugs were imported without issue into a local Launchpad
instance. Now onto staging...

The bugs are being loaded into qastaging as I write this:

  https://bugs.qastaging.launchpad.net/ares

Let me know if you spot anything obviously awry.

1515 bugs were imported without issue into qastaging. Looking good. If
you're happy we can can probably get them into production today.

Any news on an updated bug export file?

Hi, sorry for the lack of news; we did identify a small number of issues with the export (e.g. duplicates aren't linked) and I have a half-finished version of the updated exporter, but real life demanded attention, so I couldn't finish it yet.
With luck, I can get it done by tomorrow, otherwise I'll do it over the weekend.

Alright, it's taken way longer than expected, but I finally have an updated export file, including a whooping 16 megabytes of additional data: http://bugs.renegadeprojects.com/uploads/Ares-LaunchPad-Import-20111122-232855.xml
I've checked it with rnv against the newer bug-export.rnc, and it's reporting no issues.

I have a question, too: This particular version attaches attachments it cannot associate with a comment with the first comment, the bug-history-comment - is that an issue? Will that produce errors, lead to lost attachments or similar Bad Things(tm)?

I notice you have descriptive bug nicknames, like "superweapon-scatter". This means that you can go to https://launchpad.net/bugs/superweapon-scatter and be redirected to Launchpad's import of that bug.

Some users use this to set up a redirect from their old bug tracker. For example, a redirection rule could be configured from http://bugs.renegadeprojects.com/some/path/${bug_num} to https://launchpad.net/bugs/ares-${bug_num}.

Let me know if you'd prefer that. I already have a script to set nicknames to ${project_name}-${bug_num} so you wouldn't need to prepare another export file. (The script can also copy the current nickname into a tag before setting it if you wish.)

Right, I'll get on with importing this new file locally.

That is an interesting idea and certainly has its advantages, but I think a clean slate is preferable at this point - the alternative feels like those bugs would still be anchored to the old system, like the move isn't complete yet.

After all, I have the methods to generate those nicknames here...I can easily build a tool that creates an old id -> nickname association, and use that for a redirect rule. So having the nicks like that isn't essential for a redirect.

So to sum it up, thanks for the idea, but we would like to use proper, name-based nicknames. :)

Thanks Gavin Panella, that solved my question.