Bug expiry reactivated
Published by Martin Pool February 9, 2011 in Coming changes
As we foreshadowed last October, bug expiry is now active again.
Bugs that are marked Incomplete and that haven’t been touched for 60 days will now start moving to the Expired state. If it turns out the bug’s still useful or valid, anyone can move it back.
We recommend people use the Incomplete state to mean: if this bug report doesn’t get more information, there’s nothing we can do with it.
This only affects projects expire incomplete bug reports setting turned on in the Configure bug tracker page.
New ‘web_link’ property on API objects
Published by Martin Pool February 7, 2011 in API, Cool new stuff
Launchpad has a REST API that exposes almost every object within Launchpad. Most of them have API URLs that closely match the human-readable URL: for instance, https://bugs.launchpad.net/bugs/316694 can also be obtained in machine-oriented JSON or XML form from http://api.launchpad.net/1.0/bugs/316694. (The “1.0” in that URL means this is in the 1.0 API namespace.)
Previously, many Launchpadlib clients used string transformation to get from the API URL to something they could show a human in a web browser.
We’ve just added a web_link property on all Launchpad objects, so client applications can (and should) now just use that instead. Because this is just sent in the object representation you don’t need to upgrade launchpadlib to see it.
Should bug search match target names?
Published by Robert Collins in Bug Tracking
We have a small quandry on the Launchpad development team at the moment. As bug 268508 discusses, when one searches for a bug on Launchpad we do a substring search on the names of bug targets.
For instance, searching in Ubuntu for ‘gcc’ will return all bugs on the packages ‘gcc’, ‘gcc-4.4’, ‘gcc-4.3’, ‘gcc-3.3’ and so forth. Likewise search for bugs in a project group will do a similar substring search on each of the individual projects in the project group.
It turns out that doing this search is itself expensive. I asked on the Ubuntu devel list about turning it off. We would close bug 268508 and also significantly improve search performance.
However this is a possibly contentious change – there was one mail strongly in favour of the current behaviour – so I’d like to get this change proposed to a wider community.
If you’ve got a strong opinion – that the current behaviour is good, or like bug 268508 describes, that its a poor behaviour and we would be better off without it, then I’d love to hear from you. Just leave a comment on this post, drop me an email – robert at canonical.com – or post to the launchpad-users mailing list.
Thanks,
Rob (LP technical architect)
SourceForge code imports are disabled
Published by Francis J. Lacoste February 3, 2011 in General
Following the SourceForge compromise, the SSL certificate for SourceForge subversion changed.
A bug on their end prevents us from automatically importing from their SVN repositories.
Until that bug is resolved, all SourceForge code imports are disabled.
2011/02/14 update: We re-enabled SF code imports since the problem was fixed on their end.
Launchpad read-only 23.00 UTC 9th February 2011
Published by Matthew Revell February 1, 2011 in Notifications
Launchpad’s web interface will be read-only, with other aspects offline, for around 90 minutes from 23.00 UTC on the 9th of February 2011.
Starts: 23.00 UTC 9th of February 2011
Expected to be back to normal by: 00.30 UTC 10th of February 2011
This is to allow for an update to the structure of Launchpad’s database as part of our monthly development cycle.
Announcing Launchpad squads
Published by Francis J. Lacoste January 31, 2011 in General
We’ve made some changes to how we organise the Launchpad team!
We’re no longer divided into application-based teams (Bugs, Code, Foundations, Registry, Soyuz and Translations). Instead, we now have five cross-domain engineering squads: three focused on features and two on
maintenance.
How does this affect you?
When you want to speak to someone about a specific part of Launchpad,
whether for help, to escalate something or about an operational issue,
things have changed a little.
Specifically:
- For help and any other operational issues related to Launchpad, you should either send an email to the launchpad-users mailing list, or file a question on the Launchpad project. (Reminder: these forums are public.)
- If your request would benefit from interactive discussions, drop by in#launchpad on Freenode where one of the people working on the maintenance squads will be able to help you. If your request isn’t suitable for public consumption, you can reach the same people on the #launchpad-ops channel onthe private Canonical IRC server.
- To prioritize feature requests and to escalate other bugs, you should contact our product strategist.
- You can also always bounce ideas to the developers list.
Short-term, we also expect some churn as people are exposed to areas they weren’t used to before. But down-the-line, we’ll have much more distributed knowledge coverage across the whole application.
How the squads work
The squads will alternate between “development project” and “maintenance” modes.
The three development squads will work on longer term projects, usually resulting in new functionality. Once such a squad has finished a project they’ll swap places with one of the two maintenance squads.
Bugs, operational issues and so on will be taken care of by the maintenance squads.
Deciding which development projects to take on will remain the responsibility of our strategist (Jonathan Lange) in collaboration with the Launchpad Stakeholders group.
You can find a list of who is in each squad on our dev wiki.
Why are we doing this?
Our app-based teams served us well, but were becoming a liability:
- Many parts of Launchpad, such as Blueprint, didn’t have a dedicated team and were basically unmaintained.
- Each team was responsible for both new features within their app as wel as maintenance. That slowed both of these.
- Projects that required cross-app integration suffered from hand-off and coordination problem.
With this new structure, we expect to see:
- Better cohesion across the application, as one squad will be responsible for the implementation of new aspects across the whole application.
- Reduced cycle-time both for bug fixes and for new features as the context-switching will be removed.
It will be my pleasure to answer any questions you might have regarding this reorg.
Code hosting offline 12.00-12.20 UTC 26th January 2011
Published by Jonathan Lange January 25, 2011 in Notifications
Launchpad code hosting will be offline between 12.00 and 12.20 UTC for hardware maintenance on Wednesday, January 26. That’s tomorrow. This means you will be unable to push to, pull from or browse code hosted on Launchpad. All other Launchpad services will be unaffected.
Offline: 12.00 UTC 26th January 2011
Expected back by: 12.20 UTC 26th January 2011
We’ll update this post and our status feeds as soon as we’re back online.
On Friday, our codehosting server went offline unexpectedly. Turns out this was due to a hardware failure. Tomorrow, we will be fixing the underlying hardware problem, but that will mean more downtime. Sorry.
Update: The hardware upgrade went well, code hosting is back online.
code hosting offline
Published by Martin Pool January 21, 2011 in General
Due to a hardware failure, bazaar.launchpad.net is offline at the moment. We expect it will be back up and working correctly in about an hour or two from now. (That is, by about 17:00 UTC on the 21st of January.)
This affects all bzr-branch-related services: ssh and http access to branches, and also browsing of branches.
If you saw an “incorrect data check” error or similar from bzr while branching from Launchpad, this is probably the reason why, and the problem should be fixed soon.
Update: Code hosting is now back online. We’re sorry for the inconvenience.
Team polls restored, but future is unclear
Published by Curtis Hovey January 11, 2011 in General
We restored team polls because several Ubuntu teams require their use in their charter. They cannot easily switch to another service because it is not possible to organise the members to vote. We decided that to restore them while we decide what to do.
Option one: Contributors re-invent the UI so that setting up a poll is uncomplicated by silly restrictions and requirements. Many teams are not using Launchpad because they want condorcet polls. Launchpad may require them to keep the feature.
Option two: provide the information teams need to use another poll service. Team members can hide their email addresses, so it is not possible for the team admins to gather the member information to setup a poll. Honouring member privacy may require choosing or setting up a poll service that uses OpenId.
There is an unstated issue that options one and two do not address. It is also not possible to contact every member of team in Launchpad. How do team members ever know when a team admin creates a poll? Regardless of if the poll is in Launchpad, or in another service, members are unlikely to participate unless they happen to see the poll while visiting the team page in Launchpad. How often does that happen? Why would I visit my team’s page? I visit the teams I admin because I review membership proposals, moderate list mail and check on PPAs. I have no reason to visit the page of a team that I am just a member of.
Tracking PPA download statistics
Published by Julian Edwards in API, Cool new stuff, PPA
An long-requested feature in Launchpad is to let people see who’s using a PPA. Finally, we’ve implemented this!
Initially, the stats are only available on Launchpad’s webservice API. but we aim to show something useful in the web UI at some point.
If you are already familiar with the webservice API, then you can use the following binary_package_publishing_history object methods to retrieve the information:
- getDailyDownloadTotals
- getDownloadCount
- getDownloadCounts
Fabien Tassin is already using the stats to see how many people are using his daily build PPAs, and wrote an interesting blog post about it.
