Error e3d6ec94-aa94-11e2-9ec1-2c768aafd08c doesn't get the right Package field

From IRC:
[10:03:42] <seb128> ev, https://errors.ubuntu.com/problem/4e7901e5fabda4c7b5f81a3999b7d9d3afc92591
[10:04:13] <seb128> ev, do you know why it managed to take a compiz version for that issue?
[10:04:31] <seb128> ev, one report has "1:0.9.9~daily13.03.29-0ubuntu1" as version, which is compiz and not unity
[10:04:54] <seb128> ev, which makes the issue be red on the bugslist since that version is newer than the unity upload that has the fix
[10:05:21] <seb128> ev, https://errors.ubuntu.com/oops/e3d6ec94-aa94-11e2-9ec1-2c768aafd08c is the instance
[10:05:52] <seb128> ev, unity is a bit of a special case, because it's compiz which hits the segfault but we use the apport hook to redirect to the right component
[10:06:25] <seb128> ev, I'm just surprised e.u.c regrouped issues from difference sources packages (which is leading to the version issue)
[10:15:37] <ev> seb128: looking at source_compiz.py, we only switch over to unity as the binary package in the report if the user selects "yes" in the dialog that asks them if it's a bug in unity
[10:17:24] <seb128> ev, hum, no, in case of segfaults we return in the first if case
[10:17:29] <seb128> if "Stacktrace" in report:
[10:17:30] <seb128> ...
[10:17:34] <seb128> report.add_package_info(apport.packaging.get_file_package(words))
[10:17:34] <seb128> return
[10:17:50] <seb128> ev, so we don't ask the question in case of segfaults
[10:17:50] <ev> ah right
[10:18:31] <seb128> ev, but even if that was buggy, is that normal that identical bugs on different sources are "merged" together?
[10:18:44] <seb128> ev, that create the issue with the versions
[10:19:07] <seb128> wouldn't it be better to have 2 separate bugs in the tracker, one for the compiz source and one for the unity one?
[10:19:17] <ev> seb128: the problems are keyed based on the crash signature or duplicate signature, the package doesn't come into play
[10:20:51] <seb128> ev, hum, I see
[10:21:08] <seb128> ev, could we have the table of versions be a combo source/version in that case?
[10:21:34] <seb128> ev, or do you have an idea on how to avoid having that bug flagged as regression when it's not?
[10:21:59] <ev> seb128: yeah, this is definitely worth fixing. I don't mean to suggest that we're operating perfectly in this case.
[10:22:02] <ev> creating a bug for this now

Thoughts:

One option would be to only set the FirstSeen and LastSeen fields if the Package name matches what we have in BucketMetadata, but I worry that if an issue spans several packages over time and regresses, we'll mask it.

Perhaps we really want to track the tuple of (package, binary package version) for the FirstSeen and LastSeen fields. That is, we could set LastSeenCompiz to 1:0.9.9~daily13.03.29-0ubuntu1 and LastSeenUnity to something else.

When checking for a regression, we do a range scan to get all the LastSeen* fields, checking the value against the most recent binary version for each one. If any are the same as the most recent binary version, it's a regression.