bugwatch should also preserve the real status change date of the upstream bug
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
Low
|
Unassigned |
Bug Description
Currently a bugwatch only shows the date when the bugwatch itself recognized a status change upstream. This date can differ from the real date when the upstream bug was changed due to the fact that the bugwatch checks periodicaly for changes, which - in general - gives a good idea on when the actual change was. But on the other side there are also a lot of cases where the difference is so huge that the date leads to a wrong conclusion on when the change has actually been made.
To give an example:
The bugwatch https:/
The same applies to all those bugwatches that failed to update for some time and are ways out of sync that way. Others bugs are reported in launchpad while there was already an upstream bug. Take bug https:/
I think for internal use the bugwatch changed date is fine, but it doesn't give me any real information.
Note that this would also make it easier to determine if a bug should be fixed by a new upstream release by just knowing the upstream release date and looking at the date of the last status change.
I have written a function in python to do this for the gnome bugzilla activity log: http:// paste.pocoo. org/show/ 234633/
The output for the activity log of gnome bug 619347 (https:/ /bugzilla. gnome.org/ show_activity. cgi?id= 619347) is the following:
>>>
Status change on 2010-05-29 22:31:02 UTC: UNCONFIRMED -> NEEDINFO
Status change on 2010-06-01 07:08:27 UTC: NEEDINFO -> UNCONFIRMED
Status change on 2010-06-05 22:30:26 UTC: UNCONFIRMED -> NEW
Status change on 2010-06-05 23:47:43 UTC: NEW -> RESOLVED FIXED
Status change on 2010-06-21 11:26:38 UTC: RESOLVED FIXED -> REOPENED
Status change on 2010-06-21 15:01:29 UTC: REOPENED -> RESOLVED FIXED
<<<
Of course only the last status change would be relevant for the bugwatch, but the function can be used in a very flexible manner.