Not recorded whether an error is in a -proposed or -updates package
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Daisy |
Fix Released
|
Medium
|
Unassigned | ||
Errors |
Fix Released
|
Medium
|
Unassigned | ||
Whoopsie |
Fix Released
|
Undecided
|
Unassigned | ||
apport (Ubuntu) |
Fix Released
|
Undecided
|
Martin Pitt | ||
Precise |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Currently there is no way to tell whether an error report is from a package in -proposed or -updates.
This would be particularly useful for -proposed, to tell whether a proposed update should be approved.
[Originally suggested by someone in <https:/
SRU INFORMATION
---------------
FIX: http://
REGRESSION POTENTIAL: Very low; the worst that can happen is that the fix breaks the ubuntu hook (this would not break the bug filing, but does break the additional checks and information that is added to the report by the following code in the Ubuntu hook).
TEST CASE:
- Run "apport-bug" on a package which is currently in -proposed, but not -updates (for example, "apport" while it is being tested). Check the details expander, it should have a "package-
- Run "apport-bug" on a package which is neither in -proposed nor -updates, for example "apport-bug coreutils", and then on a package which is in -updates (and possibly also in -proposed), for example "apport-bug unity" at the time of this writing; In neither case the information should have a "package-
- Verify that in none of these cases you see any errors/exceptions on stderr.
There are two ways to approach this.
We can use the Launchpad API to check each package for each problem in the 'most common problems' API. If the version number for the most recently published version in -proposed is in the BucketVersions column family for the given problem identifier, show it in the '-proposed' filtered view of the table with the frequency value from BucketVersions.
The downside to this approach is that we do not know definitively if the crash occurred in -proposed, -updates, or the main archive since we're basing the judgement entirely on version numbers and not where each user obtained the package from. So the -proposed view might be polluted with errors that are occurring in -updates because those version numbers also existed in -proposed.
The second, though more invasive and forward- looking- only approach is to include the package origin data when creating an apport report. This could then be sent with the rest of the report to daisy, which would then maintain a separate view of the most common problems table data for each archive (ubuntu, ubuntu-proposed, ubuntu-updates, etc). We wouldn't have the pollution issue mentioned above because we'd be basing the counts entirely on the archive the errors occurred in.
Martin, Matthew, Brian, Kate, others, what do you think?