./lp-bug-dupe-properties --reporter --bug 1234567
LP: #1234567 has 40 duplicates
brian-murray: 2345678 3456789 …
So bug 1234567, a fake example, isn’t as important as the duplicate count would have led you to believe, but there are more things it would be good to know about duplicate bugs. Like when they were reported:
./lp-bug-dupe-properties --bug 902603 --day
LP: #902603 has 250 duplicates
2011-12-10: 902605 902606 902607 902608
2011-12-11: 902775 902776 …
Or the release tags that the duplicates possess.
./lp-bug-dupe-properties --bug 902603 --rtags
LP: #902603 has 250 duplicates
precise: 902605 902606 …
Finally one thing specific to Ubuntu that would be quite helpful are the values of apport keys that appear in the bug description. For example:
./lp-bug-dupe-properties --bug 708517 -D Package
LP: #708517 has 52 duplicates
plymouth 0.8.2-2ubuntu17: 725753 725754 730377 734480
plymouth 0.8.2-2ubuntu18: 738127 738374 739290 739712 740071
Here we’ve checked the bug description of every duplicate to see what value appears in the Package key of the description that was created by apport. This was useful to tell what the latest version of the package the bug was reported about.
lp-bug-dupe-properties was just merged into the bzr branch of lptools. I hope you find it useful.]]>
I created the video mostly following the instructions at the Canonical design blog. I recorded separate screencasts for each way of confirming the task, that way they can be easily replaced if Launchpad changes. Text slides, instead of audio, were used to make production easier and also to allow for easy translations.]]>
So I wrote a new Launchpad Greasemonkey Script to display the quantity of duplicates in the duplicates portlet.
I’ve hightlighted the duplicate count in the screenshot to really point out where it is.
I’ve also updated the firefox-lp-improvements PPA which contains a Firefox extension collecting all of the Launchpad Greasemonkey scripts with the new script.]]>
When I was working on the Launchpad team at the EPIC in July I remembered the issue I was having and discovered that I was doing it wrong. I needed to use launchpad.people[’brian-murray’].setLocation() and not launchpad.me.setLocation(). Then Google Maps were removed from people pages like mine and I was sad again.
Surely, there is is a happy ending to this sad tale?
Indeed, Santa has arrived a bit early and brought me a Launchpad Greasemonkey script that displays Google Maps on Launchpad user pages again. It is now available in firefox-lp-improvements. So please set your location to interesting and approximate places!
It appends some additional bug searches to bugfilters portlet on Launchpad. A question mark is displayed for the bug count as there isn’t an easy way to discover this number. I think there are some really powerful searches included (Incomplete w/ response, Bugs I reported, Bugs I am subscribed to) which are quite handy to have one click away. I’ve also added this to the firefox-lp-improvements ppa.
If you have any ideas of additional searches to add in please let me know!]]>
Of course this would be much more useful if you could access it using python-launchpadlib. So I’ve exported bug.activity in the devel version of the API and now you can do interesting things like the following:
bug = launchpad.bugs
[(a.datechanged, a.person.display_name) for a in bug.activity if a.newvalue
and "regression-potential" in a.newvalue]
[(datetime.datetime(2010, 9, 5, 1, 50, 30, 602479, tzinfo=TimeZone(0)),
Now we know that Scott added the tag regression-potential to the bug on September 5th. Pretty neat!]]>
I have and thought it would be helpful to know which duplicate I was subscribed to rather than having to look at every duplicate to see which one was mine. You can now determine this on edge by mousing over your name in the “From duplicates” portion of the subscribers portlet.
I recently fixed one of these cases - where if you were to search a distribution series, Maverick for example, for bug tasks via the API you would receive an empty collection. Of course, this makes no sense as Maverick is being actively worked on and it has bug tasks targeted to it. The bug tasks are hidden because omit_targeted parameter had a default value of True. While it is easy to work around by setting omit_targeted to False, this isn’t easily discoverable nor should it even be necessary. If you are searching tasks for a series you want to see the targeted ones!
Anyway, its fixed now but you need to be using the devel version of the API.]]>
So now when you are assigned a bug report you will receive an email with following in the body.
You have been assigned a bug task for a public bug by Brian Murray (brian-murray):
Its more than just s/subscribed/assigned/ because the assigner is actually identified - something that was not done before. Another fix made was preventing the assignee transition email notification from going to the assignee. You previously would get 2 emails when assigned, if you were not a bug subscriber, a notification about the new to you bug report and the assignment transition.
After fixing that bug I went ahead and fixed a bug that was bothering me in 2007! I wanted, and still want, to be able to filter on bug reports that I’ve reported which isn’t possible since I’m just listed as a subscriber. This particular bug really was easy (3 lines of code, 2 lines of comments and 7 lines of test) and now you can filter on an “X-Launchpad-Reporter:” header.
Okay not really now. Due to the way email notifications are sent you won’t actually be able to see these changes until they land on the production server next week.]]>