Two months of squads: reviews and prospects
Published by Francis J. Lacoste March 18, 2011 in General
Launchpad has been operating in the squad structure for two months now. From my point of view, things have been going very well.
We are making steady progress on fixing timeouts, OOPSes, regressions and other operational issues.
The blue squad switched to maintenance after completing the ‘daily build’ project. The orange squad should follow-up soon once they complete the ‘sharing translations upstreams translations in Ubuntu’ project.
The cross-domain pollination is paying off. Having the API expert working as part of the squad finishing off the ‘daily builds’ work resulted in a long-due overhaul of our AJAX infrastructure. See the drive-by ajaxification of the blueprint page for the results! We saw similar things happen on the orange squad where the knowledge around the job system was put to good use.
I’ve got a lot of good feedback from developers who enjoy the enhanced focus they get in this new configuration.
As expected, the pace is picking up as the new squads learn to operate better together. The average of bugs closed per week went from 63 to 84.
At the last Thunderdome (whole Launchpad team in person-meeting) where we kicked off the reorg, I issued a challenge: by the next Thunderdome (scheduled for the last week of June) we should:
- have no timeouts with a cut-off at 9s;
- have an empty critical bugs queue;
- be on our way to delivering new features within 45 days on average
The next Thunderdome is now 3 months away. How are we doing?
Yesterday, Robert announced that the timeout was lowered to 11s. That means we have 2 seconds left to go! Looks like this is going well.
On the second point, we have today 224 open critical bugs on the Launchpad project. We started at 264. So on the surface, it’s not going well. The trick here is that there were a lot of issues that weren’t on the list. So we kept finding new issues as we fixed some, giving an impression of stasis. Over the last two weeks though, we have seen a constant drop in the queue length, so I hope that all issues are now recorded and that we are on are way to burning this queue down. The fact that we are now closing 34 of those per week on average (over 21 per week when we started) gives me comfort. We need to make that number go down by 16 each week to reach our goal. So it seems well within reach!
The last one is more challenging. We have a big structural constraint that would make it hard to achieve a cycle time of 45 days on new features: our DB deployment story. Most feature will require two DB patch iterations and we deploy those every 30 days. Nonetheless, we could read this goal as getting slots free on our ‘Next’ queue. That means finishing off everything that we have in progress plus some things that we haven’t started yet. We have some big items on there. Things like derived distributions and getting our bug privacy manageable. That’s where our real challenge lie! I’m looking forward to see how this will go.
Launchpad needs a command line
Published by Martin Pool in clients
Launchpad has a web UI, an email interface, and a ReST API that exposes every object in the database.
There are also a bunch of client programs, command line and graphical, that talk to Launchpad to do various things.
What we don’t yet have, and what I think would be great, is a systematic client that lets you manipulate
everything from the command line. There’s some code that starts towards this in Hydrazine, lptools and others, but I think having just a single tool that eventually does everything would be more discoverable and avoid unnecessary fragmentation or duplication.
(That’s not to say there’s not room for others that are guis, that are specialized to particular projects or that encapsulate a lot of policy or opinion about what they’re doing.)
So dobey and I have agreed to gradually merge hydrazine into lptools, and with other people to work towards making lptools cover everything you can do through the web UI or the API. If you have scripts you’ve written yourself, perhaps you’d like to merge them in.
pad.lv: short Launchpad URLs
Published by Martin Pool in Cool new stuff
Short story: http://pad.lv/12345 takes you to bug 12345, and pad.lv describes more abbreviations.
Sometimes you’d like to point people to an interesting bug in a project that uses Launchpad, like bug 685380 (that ‘1’ and ‘l’ may need to be more distinct in the new Ubuntu Font).
Typing out https://launchpad.net/bugs/685380 is a bit tedious, and it uses up a fair bit of space in a microblog entry. You can use any of innumerable URL-shortening services, but then the URL’s opaque; which is a shame since it really just wants to represent a 6-digit number.
Therefore: pad.lv (pad love), transparent short URLs for bugs, and other things including projects, people, bug-filing forms, packages, and more.
Maybe someone would like to make bookmarklets that generate these links, or add them into the Launchpad UI?
Thanks to Latvia for letting us use a fraction of their domain name space!
Launchpad Package Upload Improvements
Published by Julian Edwards March 10, 2011 in Cool new stuff
Launchpad has an anonymous FTP server that people use to upload source packages to Ubuntu and their PPAs. When Launchpad processes the upload it does a huge number of checks, one of which is verifying the GPG signature on the upload’s .changes file.
One of the problems with this is that if there’s a problem with the signature, or there is no signature at all, Launchpad simply throws the upload away as it cannot be sure who uploaded the package. If it tried to send an email it would also quickly become a spam vector! (See bug 374019)
In today’s release, there is a brand new FTP server that will do preliminary GPG signature checks right in the FTP session itself. If you upload a package that is not signed properly, you’ll see a message that looks like this:
Uploading to launchpad (via ftp to ppa.launchpad.net):
Uploading hello_2.5-1ubuntu1.dsc: done.
Uploading hello_2.5-1ubuntu1.diff.gz: done.
Uploading hello_2.5-1ubuntu1_source.changes: 1k/2k550 (‘Changes file must be signed with a valid GPG signature: Verification failed 3 times: [“(7, 8, u\’Bad signature\’)”, “(7, 8, u\’Bad signature\’)”, “(7, 8, u\’Bad signature\’)”] ‘,): Permission denied.
Note: This error might indicate a problem with your passive_ftp setting.
Please consult dput.cf(5) for details on this configuration option.
which means you get immediate feedback instead of your upload disappearing entirely!
As a bonus, this new FTP server also fixes another long-standing bug where uploads would hang with 1k left to go.
This checking is not available on the SFTP service yet, but we hope to implement that in the near future.
Launchpad read-only 09.00 UTC 10th of March 2011
Published by Matthew Revell March 8, 2011 in Notifications
Unfortunately, we have to move this week’s Launchpad database update. The previously announced service interruption due on Wednesday the 9th of March will now take place on Thursday the 10th of March.
Launchpad’s web interface will be read-only, with other aspects offline, for around 90 minutes from 09.00 UTC on the 10th of March 2011.
Starts: 09.00 UTC 10th March 2011
Expected back by: 10.30 UTC 10th March 2011
I’m sorry for the short notice of this change. One of our operational sysadmin team is ill, meaning that we won’t have cover during the time that we had originally planned.
Other ways to get Launchpad status information
For all the latest status information about Launchpad, see our identi.ca or Twitter feeds.
To receive email about major Launchpad service disruptions, such as this, join the launchpad-announce list.
Launchpad read-only 23.00 UTC 2011-03-09
Published by Matthew Revell February 24, 2011 in Notifications
From 23.00 UTC on the 9th of March 2011, Launchpad’s web interface will be read-only, with other aspects offline, for around 90 minutes. This is to allow us to make an update to the structure of the Launchpad database.
Starts: 23.00 UTC 9th of March 2011
Expected back by: 00.30 UTC 10th of March 2011
Get an overview of what we’re doing
Published by Jonathan Lange February 21, 2011 in General
Ever wanted to know what exactly is happening in Launchpad development, but found our list of in-progress bugs too daunting and detailed? Well, do we have a link and a screenshot for you.
Screenshot:
Link. (Log in: guest@launchpad.net; Password: launchpad).
Thanks to the nice folk at LeanKit Kanban, we’ve now got a guest account set up so that anyone can our kanban board. The board shows all of the high level features that we are working on (those are the green ones), the infrastructure projects we’re doing (those are the blue ones) and all of the community-driven work that we know about (the yellow ones).
The further to the right a card is, the closer it is to being done. The cards in the Next column are the things we’ll start to work on once we’ve got room on the board to start them. “UA” means we’re fixing the final few bugs in a feature before we consider it to be done, and “Deployment” means that we need sysadmins to do something.
Our goal is to keep the amount of work-in-progress down to a small number, and to be able to move things from left to right as quickly as possible. We hope making the board available gives you a better insight into Launchpad development, and maybe even encourages you to join in the fun.
Update: We’ve fixed the log-in credentials, for real this time. Sorry for publishing the wrong ones previously, and previously before that.
“Failed to fetch” errors for PPAs …
Published by Martin Pool February 18, 2011 in PPA
You may start getting “Failed to fetch” error messages when updating your software sources (e.g. through “apt-get update” or “Reload package information” in Synaptic), which may be due to a bug we’ve just cleaned up in Launchpad’s PPAs.
The error looks like this:
W: Failed to fetch http://ppa.launchpad.net/chromium-daily/ppa/ubuntu/dists/maverick/Release Unable to find expected entry restricted/binary-i386/Packages in Meta-index file (malformed Release file?) E: Some index files failed to download, they have been ignored, or old ones used instead.
Launchpad’s UI is evolving
Published by Curtis Hovey February 17, 2011 in General
We are updating the UI over several iterations over the next few weeks for several reasons:
- Launchpad should apply the Canonical guidelines for websites to take advantage of the research done for other sites. Being consistent with other Ubuntu and Canonical sites means there is less for users to learn about what the presentation means.
- Launchpad has 730 style rules. Most are dedicated to defining exceptions, not standards. 730 rules is too much, too much for developers to maintain, too much for users to understand.
Many users have remarked about Launchpad’s recent the loss of colour. We did this because:
- It is hard to learn the meaning of so many colours.
- It is confusing to see headings of different colour that have the same meaning.
- Answers and Blueprints used blue, the same colour as links.
- There were inappropriate uses of green that confused users who know that green means “perform an action without leaving the page”.
- The were uses of orange and purple that users might mistake for Canonical’s aubergine and Ubuntu’s orange.
We appreciate your feedback, and we would like to hear more. There are also legitimate concerns being raised and we are not surprised because they are the same concerns we discussed.
1. Headers are harder to identify
Indeed they are. The old colours were hiding the font-size and whitespace issues that are still present in Launchpad. I am working on this issue right now. Launchpad uses many font sizes, and the percentage mechanism used does not render the size developers intend (font size smaller than default creates accessibility and usability difficulties). I think headers will be easier to understand when there are fewer, but distinct, font-sizes being used.
2. Buttons, callout actions, are hard to find
The links to report a bug for example look like normal links. They are hard to see. These important actions are no longer callouts. The only action that users can still find is the green download button…but that green does not mean “perform an action without leaving the page”. This is bad. We do know what to do about this yet. Maybe you can help. I think they need colour, they may need iconography. Look at http://www.ubuntu.com/ to see an example button and callout links. Launchpad does not have a colour at this moment. Launchpad does not have an obvious position along the axis described in the website guidelines (Canonical, corporate, aubergine)..(Ubuntu, community, orange). Launchpad definitely has both aspects; Canonical created Launchpad to build Ubuntu. I think there is a second axis for upstream projects (corporate and community, hosted and mirrored, Ubuntu and other OSes) that might need a colour. Most of the links that I think of are about participation in community, so I favour orange. But is this right? Does the orange also mean Ubuntu to non-Ubuntu users? Will the use of orange stop users from reporting a bug in the OpenStack project?
Bug search no longer does substring matching of source package names
Published by Robert Collins February 16, 2011 in General
As part of improving performance we have disabled the substring matching of source package names. This fixes bug 268508 and bug 607960. However its a slightly contentious issue – opinions vary about whether bug 268508 is a valid bug or not.
So we have only disabled it – the code is still present and when we have more leeway on the performance of bug searching we’ll revisit this and look into some design and UI analysis to decide whether substring matching of this sort should be done or not.
For now though, there should be less timeouts in bug searches.
