[Request] Staging import of bug data for project Ares
Good day,
could you please do a staging import of the bug data at http://
The file is 170 MB big, so depending on your pipe, you may want to wget on the server directly.
Thank you! :)
Question information
- Language:
- English Edit question
- Status:
- Solved
- Assignee:
- Gavin Panella Edit question
- Solved by:
- Gavin Panella
- Solved:
- 2011-11-25
- Last query:
- 2011-11-25
- Last reply:
- 2011-11-25
- Whiteboard:
- 2011-11-07 bigjools: Assigned to LOSAs 2011-11-08 allenap: Assigned to me to do prep work.
Gavin Panella (allenap) said : | #1 |
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.
Gavin Panella (allenap) said : | #2 |
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.
Renegade (renegade) said : | #3 |
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?
Renegade (renegade) said : | #4 |
Please try http://
Gavin Panella (allenap) said : | #5 |
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.
Gavin Panella (allenap) said : | #6 |
Also, if you want to chat you can get me in #launchpad on freenode.
Renegade (renegade) said : | #7 |
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://
Gavin Panella (allenap) said : | #8 |
1515 bugs were imported without issue into a local Launchpad
instance. Now onto staging...
Gavin Panella (allenap) said : | #9 |
The bugs are being loaded into qastaging as I write this:
https:/
Let me know if you spot anything obviously awry.
Gavin Panella (allenap) said : | #10 |
1515 bugs were imported without issue into qastaging. Looking good. If
you're happy we can can probably get them into production today.
Gavin Panella (allenap) said : | #11 |
Any news on an updated bug export file?
Renegade (renegade) said : | #12 |
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.
Renegade (renegade) said : | #13 |
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://
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)?
Gavin Panella (allenap) said : | #14 |
I notice you have descriptive bug nicknames, like "superweapon-
Some users use this to set up a redirect from their old bug tracker. For example, a redirection rule could be configured from http://
Let me know if you'd prefer that. I already have a script to set nicknames to ${project_
Right, I'll get on with importing this new file locally.
Renegade (renegade) said : | #15 |
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. :)
|
#16 |
All done. If you have any problems you know where to ask :)
Renegade (renegade) said : | #17 |
Thanks Gavin Panella, that solved my question.