Getting your code into Launchpad
Published by Matthew Revell January 29, 2010 in General
Brad has written a great guide to writing and committing your first code for Launchpad.
Amongst other things, he has a useful bullet list that describes the steps between deciding you want to write code for Launchpad and actually seeing your work in place.
“The steps for fixing a bug or adding a new feature in Launchpad are:
- Find a bug or feature request. The best place to look is on the milestone for the application of interest. (See the list for Launchpad Registry’s 10.02 milestone).
- Research the problem.
- Have a pre-implemention call.
- Grab the latest branch of Launchpad (which we informally call ‘rocketfuel’). You can use ‘rocketfuel-get’ to update your copy of devel and ‘rocketfuel-branch’ to make a branch for your work. It’s best to create a new branch for each chunk of work you do.
- Write your tests, write the code, repeat. (Read about TDD.)
- Push your code to Launchpad (‘bzr push’).
- Create a merge proposal (‘bzr send’).
- Have a review, fix changes, repeat.
- Run the tests. At a minimum you should run all the tests for the application you changed. For bugs you can do that with ‘bin/test -vvm lp.bugs’.
- Submit to PQM.
- QA the change when it lands on edge or staging.
- See the change in production when the next release rolls out.
- Bask in your awesomeness.”
If you want to fix a bug or get a feature into Launchpad, go read Brad’s post.
Feeling the heat
Published by Matthew Revell January 27, 2010 in Bug Tracking
Ascertaining the importance of a bug can be one of the harder parts of bug triage, right?
It’s no problem if the project’s relatively small and you’re intimately involved with each bug but if you’re helping to triage for a larger project, it’s not always that easy.
To help, we’ve introduced a new indicator of how hot a particular bug is. A bug’s heat is a calculated estimate of its importance, using factors such as how many people are subscribed, whether it’s a security issue, how many people have marked the bug as affecting them, and so on. Note that it is not a replacement for the bug’s human-set importance but rather an aid to the people deciding what the importance should be.
You can see the full details of how bug heat is calculated on our wiki page.
A bug’s heat is shown on the bug report page as four flame icons. The hotter the bug, the more of the icons are lit. You can also sort bug search results by bug heat.
There’s a bug at the moment that means there’s a fairly high barrier for a bug report to jump before any of its flames light up but take a look at the Ubuntu bug list, sorted by bug heat, and you’ll see the new bug heat icons in action.
Let us know how you’d like to use bug heat.
Improved Bug Patch Notifications
Published by Deryck Hodge in Bug Tracking
There are a couple of new features related to patch handling in Launchpad bugs this month.
Building on the work we did in December to better distinguish patches in bug pages, we now use an icon to show if a bug has a patch attached in bug listings. Any search on Launchpad will now indicate if a bug has a patch attached. Look for the band aid icons, and you’ll know that a bug has a patch attached.
Also, bug mail notifications have been updated to distinguish patches from any other attachment. Now when a patch is added or removed from a bug the email notification will read “Patch added” or “Patch removed” to make spotting patches easier in email.
These are small improvements to our handling of patches to help patches become more easily spotted on Launchpad. Combined with our work on sorting bugs by a heat number, the Launchpad bugs app is doing more to let users know about the state and quality of a bug report.
ACTION: Back up old sources from PPAs
Published by Jonathan Lange January 26, 2010 in General
Now that I have your attention…
We’ve been overwhelmed by the popularity of PPAs on Launchpad. In fact, according to our sysadmins, they are a little too popular and now our disks are full.
Full disks mean no more PPAs, and no more uploads to PPAs. We’d like to add some more disks, but we can’t actually do that soon enough for a bunch of complicated reasons.
Instead, we’ve decided that we’re going to remove all of the source files for any uploads that are:
- in PPAs
- not published, that is, deleted or superseded
- have been not published for over seven days
Note that we already delete the binaries for such uploads.
We are going to delete these old files this Wednesday, January 27th. We’re really sorry that we are announcing it so close to the actual event — we know it’s a hassle.
If you want to keep any of these files, you are going to have to download them right now. Here’s how to do it.
- Go to your PPA’s web page on Launchpad and click on “View package details”.
- Change the filter to search for “Any status”. Click “Filter”.
- For each superseded or deleted upload with files you want to save, expand the upload and manually save all the files under the “Package files” heading.
If it’s a busy PPA like the example one, then there will be a lot of old versions to download. If you aren’t sure, you probably won’t need all of them. Ask on #launchpad on Freenode or the launchpad-users mailing list if you are unsure.
Launchpad 10.1 roll-out 09.00-11.30 27th January 2010
Published by Matthew Revell January 22, 2010 in Notifications
Launchpad’s web interface will be read-only, and all other parts of Launchpad offline, for roughly two and a half hours from 09.00 UTC on the 27th January 2010.
Starts: 09.00 UTC 27th January 2010
Expected back: 11.30 UTC 27th January 2010
This is for the roll-out of our Launchpad 10.01 code. We’ll post details of what’s new after the release.
Anonymous Access to the Launchpad Web Service API
Published by Leonard Richardson January 19, 2010 in General
You asked for it and we’ve delivered. Your launchpadlib scripts can now get read-only access to the Launchpad web service API without going through any authorization process. Previously, to authorize your script, you had to open a web page in the end-user’s web browser and get the user to click a button. Now, you only have to go through that process if you want to access someone’s private data or modify the Launchpad dataset on their behalf.
If you’re using the latest version of launchpadlib (1.5.4), you can log in anonymously with the login_anonymously helper method. You just have to pass in a string identifying your client, and the name of the Launchpad server you want to access.
from launchpadlib.launchpad import Launchpad
launchpad = Launchpad.login_anonymously("my client", "edge")
print launchpad.bugs[1].title
# Microsoft has a majority market share'
(That code also illustrates how the latest version of Launchpadlib lets you specify a short string like “edge” instead of having to importing a constant like EDGE_SERVICE_ROOT.)
If you’re using an older version of launchpadlib, you can log in anonymously using the login helper method. You can get anonymous access by passing in empty strings for the token string and access secret:
from launchpadlib.launchpad import Launchpad, EDGE_SERVICE_ROOT
launchpad = Launchpad.login("my client", "", "", EDGE_SERVICE_ROOT)
print launchpad.bugs[1].title
# Microsoft has a majority market share'
Right now, anonymous access only works on Launchpad’s ‘edge’ and ‘staging’ instances. It’ll be installed on production at the end of the month, with the release of Launchpad 10.01.
Bug Watch Updating Temporarily Down
Published by Deryck Hodge January 15, 2010 in Bug Tracking, General
Some Launchpad users may have noticed that we are not syncing bug watches with external trackers as we should. We have had to turn off syncing with external trackers while we work on a problem we have had with hammering bug trackers with large numbers of bug watches in Launchpad.
The Launchpad Bugs team has been doing a lot of work recently to improve our handling of bug syncing between Launchpad and external trackers. We’ve fixed several bugs. Unfortunately, we cannot re-enable syncing with external trackers until we are certain we will not hammer an external tracker.
We expect bug syncing to be down through the weekend and fixed early next week. Interested developers can follow progress at the bug linked above.
Launchpad maintenance 20th January 2010
Published by Matthew Revell January 13, 2010 in Notifications
Launchpad may be unavailable for up to 30 minutes from 11.00 UTC on Wednesday the 20th January, for planned hardware maintenance.
Starting: 11.00 UTC 20th January 2010
Expected back before: 11.30 UTC 20th January 2010
We are, though, hopeful that we can complete the maintenance without taking Launchpad off-line, in which case you will not notice any effect to your service.
The Road Ahead
Published by Jonathan Lange January 8, 2010 in Coming changes
It’s my pleasure to introduce to you the single greatest Launchpad planning achievement for 2010: the roadmap.
For the last few months we’ve been working on bridging the gap between the Ubuntu distribution and the upstreams that it’s made from: making it easier for patches, translations, and bug reports to flow between Ubuntu users, Ubuntu developers, and upstream developers.
We’ve been asking users what they want and trying really hard to listen to them. And, of course, since we’re Free Software now, all of our discussion, development and planning is out in the open.
Still, there are a lot of people who care a lot about Launchpad but don’t have time to follow our mailing list or dev wiki. In particular, Ubuntu contributors are generally way too busy making Ubuntu better to keep up with every thread there. If people who care about Launchpad can’t keep track of what we are doing, they can’t tell us how we can do it better, and they can’t cheer us on when we’re doing it right.
We needed something to keep everyone in the loop. But it needed to be something simple, since we don’t want to spend all of our time telling people what we are going to do instead of actually doing it.
At Kiko’s urgings (perhaps inspired by Jono Bacon’s roadmaps), we’ve prepared a roadmap for the next few months of Launchpad development, in which the highlights are:
- Guiding developers to the most important (hottest) bugs
- Getting patches attached to bugs into the code review system
- Automatic imports into bzr from hg (we already do git)
- Ubuntu packages built fresh each day from the latest code
And of course, there’s more on the roadmap.
We intend to keep the page up-to-date and to keep the URL constant. This means that any time you want to know what we’re planning, you can look at that page and know for sure.
Remember, it’s an expression of intent, and not an actual commitment. If we can figure out a way to better connect the world of open source software, we’ll change the roadmap in a heartbeat.
For those who aren’t content with a high-level overview, you can also look at the 10.5 series on Bugs, Soyuz, Code and so forth. See the page for our current development cycle for a full listing. And, of course, you can keep following this blog for major announcements and items of interest.
I hope you enjoy the Launchpad roadmap, and I can’t wait to hear back from you. Have a great 2010.
2010 Launchpad Release Calendar
Published by Brian Fromme December 22, 2009 in Releases
We have published the 2010 Launchpad release calendar. You’ll see that there is a new Launchpad release naming scheme as well. We have moved to a YY.MM naming, which matches the Ubuntu model. You’ll find the calendar on the Launchpad development wiki, as:
https://dev.launchpad.net/Releases/2010Calendar
Having a public release calendar is particularly useful for anyone wanting to contribute to our open source project. It is also helpful for users to know when we’re likely to have down-time or read-only time.
The calendar doesn’t cover maintenance or system status. To keep up on that, please subscribe to:
http://identi.ca/launchpadstatus
