On Thu, Nov 08, 2007 at 09:31:11PM -0500, James Henstridge wrote:
On 08/11/2007, Bryce Harrington <bryce@...961...> wrote:
Bugs appear reported in future
On this bug (and possibly others), the dates associated with buliabyak-users are in the future (2011, 2012).
This is a case of garbage in, garbage out. Take a look at the submission date of the source bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1218610&gro...
Aha, ok our bad. I wonder how this happened. In any case, now that we know it's not caused by the import this issue can be ignored.
Category mapped to milestones
For Inkscape, we used the SF Category to tag bugs by type. These appear to have been mapped to milestones by the converter, however. Instead, can you have the Categories just mapped into LP tags?
The categories are being mapped to tags. It is the groups that are being mapped to milestones (this is how Python was using bug groups). I can certainly update the import to map groups to tags as well though.
That'd be great. Yes, since SF left both these things rather freeform it's not a surprise that different projects used them in different ways. Mapping both cats and groups to tags would be best for Inkscape.
Missing Attachments
In a number of cases the bug attachments didn't come through correctly. Here is one example:
SF.net http://sourceforge.net/tracker/index.php?func=detail&aid=1816893&gro... Launchpad https://bugs.demo.launchpad.net/inkscape/+bug/159964
This is a display bug with Launchpad where it does not list attachments associated with the first comment in the main content. The attachment is visible in the attachments portlet on the left though. You can also see it when viewing just the initial comment:
https://bugs.demo.launchpad.net/inkscape/+bug/159964/comments/0I am pretty sure we have a bug open for this, but don't have it handy.
Aha, there it is. That would be a good bug to see fixed, but for now we'll just make a note to look in the portlet for attachments. (I hadn't ever noticed that before.)
Fix Committed State
It appears that the 'Pending' state in SF was mapped to 'Fix Committed' in launchpad. We never really understood what 'Pending' meant, but what we used it for in Inkscape is more like the "Incomplete" state, so it should be mapped to that.
Fair enough. If you have a preferred mapping from SF.net statuses and resolutions to Launchpad statuses, I can tweak the import to match.
Sure, here is how I'd map it, although this is only after a few minutes' thought, so there could be better mappings...
Open Closed Deleted Pending None New Fix Released Invalid Incomplete Accepted Confirmed Fix Released Invalid Incomplete Fixed Fix Committed Fix Released Invalid Fix Committed Duplicate Invalid Invalid Invalid Invalid Invalid Invalid Invalid Invalid Invalid Out of Date Invalid Invalid Invalid Invalid Rejected Invalid Invalid Invalid Invalid Won't Fix Invalid Invalid Invalid Invalid Later In Progress Invalid Invalid In Progress Postponed In Progress Invalid Invalid In Progress Remind In Progress Invalid Invalid In Progress Works For Me In Progress Invalid Invalid In Progress
Inconsistant Bug Stats
The bug numbers in Launchpad show:
Open 1144 Critical 43 New 809 Unassigned 826 All bugs ever reported 5536
while on sf we have:
# Bugs : (801 open / 3,727 total) # Patches : (27 open / 828 total) # Feature Requests : (1,022 open / 2,183 total)
We're curious how the numbers are arrived at, and what causes the stats discrepancies?
(I'm guessing it's just due to terminology differences between SF and LP status, but am uncertain how they get mapped through.)
So the break down I see in the database is:
NEW: 809 INVALID: 1993 CONFIRMED: 312 INPROGRESS: 5 FIXCOMMITTED: 18 FIXRELEASED: 2399 UNKNOWN: 16 Total: 5552
The counts shown on the Launchpad page omit duplicate bugs which would account for a small part of the discrepency. The 16 unknowns are pre-existing bug tasks that have bug watches pointing at SF.net.
I think the numbers here should be a bit higher, so it does look like some of the bugs got left out of the dump. I'll investigate and get back to you on this.
Cool, thanks.
Map priority 5 bugs to New/Undecided status
By default, SourceForge sets the priority of newly reported bugs to 5. We found this irritating since it interferes with triaging the priorities of bugs. So as a hack-around we decided that priority 5 actually means "unprioritized".
Can you set the script to map priority-5 bugs to be New/Undecided?
We currently map "Open" bugs with no assignee and not in Accepted state to NEW. So I guess mapping priority 5 to an unset importance would solve this, right?
Yes, that would do it.
Thanks again! Bryce
participants (1)
-
Bryce Harrington