The Ubuntu Foundations team has sponsored work on various improvements to Launchpad’s archive handling lately, mainly to expose various new facilities on the API where we were previously using privileged scripts. This has involved cleaning up a substantial amount of old code along the way, and it has become possible to fix some other old bugs as spin-offs.

One of these old bugs is “Archive:+copy-packages nearly unusable due to timeouts”. The +copy-packages page allows anyone who can upload to a PPA to instead copy packages from another PPA. This saves effort, and in the “Copy existing binaries” mode it can save a substantial amount of build time as well. For example, the LibreOffice packaging team uses this to deliver packages to different sets of users after they have passed various levels of testing.

Unfortunately, the very cases where this is most useful, namely large and complex packages, are also the cases where it is most likely to break. Copying large numbers of binary packages involves large numbers of database queries and can quite easily overrun the timeout for a single request to the Launchpad web application. Doing this for several series at once, a common case which seems reasonable, is proportionally less likely to work. Various attempts have been made to optimise the database interactions here, but ultimately doing lots of complex synchronous work in time for a single web request is doomed to failure.

The solution to all this is to copy packages asynchronously. For some time Launchpad has had the ability to schedule “package copy jobs” which run very shortly after the request (typically within a minute) but not immediately. For example, the Ubuntu team uses these when copying new versions of packages from Debian unstable in cases where there are no Ubuntu-specific modifications, and when releasing proposed updates to stable releases for general use after verification. A similar facility has been present in the code for the +copy-packages page for some time, but not exposed due to various bugs. We believe that these bugs have been fixed now, and so we would like to start copying packages asynchronously when requested via the web UI.

We have exposed this to beta testers first. The effect is that, if you are a beta tester when you ask for packages to be copied, you will be told something like “Requested sync of 2 packages. Please allow some time for these to be processed.” The processing should normally happen within a minute or two, and you will be able to see it in progress on the +packages page for the target archive. If it succeeds, the in-progress notification will be removed and you will be able to see the changes in the target archive. Otherwise, you will see a failure notification along these lines:

If beta-testing goes well, then we will enable this for all users, and remove the old synchronous copying code shortly afterwards; so please do report any problems you see.

If you are relying on package copies in the web UI happening immediately rather than within a few minutes, firstly, please contact us (e.g. #launchpad-dev on freenode IRC, or launchpad-users@lists.launchpad.net) as we would like to understand your requirements in more detail; secondly, you may be able to use the Archive.syncSource API method instead, which also has timeout constraints but is at least guaranteed to remain synchronous. However, we hope that most people will not have such a requirement.

The Purple squad recently updated bug reporting and searching to understand the new privacy rules. Some of the changes were requirements to support sharing, others were opportunities we took advantage of.

Improvements to bug reporting and forms

The Purple squad updated the bug reporting UI to make it consistent with the bug pages. We choose to develop one consistent and tested UI rather than update the many kinds of widgets used in bug forms.

Undecided is the first importance because it is the default importance.

Improvements to bug searching

Advanced bug search was updated after we discovered that recent changes made it possible fix some long standing issues with a few additional lines of code.

Anyone can search for Private or Embargoed Security bugs that are shared with them.

Autocomplete works with bug tags.

Usability and Accessibility fixes

We discovered that the popups that show bug status, importance and information type did not work with keyboards. It was possible to tab out of every other kind of popup by accident. We made deep fixes to the code so that all launchpad popups work with keyboard.

Nothing breaks my heart quite like a request to make a project private–make it invisible to everyone except to the people the project trusts. I am utterly crushed when someone who works for Canonical or on Launchpad asks for one. I have been planning this feature for more than two years, and the Purple squad has been working on it for 13 months. I blog about this, I send emails about this, I present reports on this, but the people who most need private projects don’t know what the Purple squad is doing. I think the problem here is that Launchpad squads no longer use Launchpad to plan and execute work. There is no place for any interested party to see what the goals of Disclosure is and gauge how we are progressing.

I present my first draft of a report that states the simple goals of that the Disclosure feature wants to achieve . The report provides some summaries of the work that allows anyone to see what the Purple squad is doing, recently done, and will do next. There is also some analysis that provides insight into the amount of work remaining. This report complements the Purple squad’s kanban board. While kanban is excellent for tracking branches of code and technical tasks, the level of detail is unsuitable for non-Launchpad developers. The kanban board is also only accessible to a small number of people. I want a report that anyone interested in private projects or managing the disclosure of private information can see and understand. Mostly, I want everyone to see that the Purple squad is delivering valuable features and know when we will be done.

I based the report on the intended reporting UI for Launchpad series and milestones. I really miss using series and milestones to plan releases. For every milestone, I wrote our goals in the summary, and targeted bugs to the milestone. Though we abandoned the analytics because of performance concerns, I could reliably judge the contributors’ velocity, and see when I needed to retarget work to another milestone because the remaining effort exceeded the milestone’s work capacity. Though I didn’t provide a burn down chart of the work, I could sort the milestone to see the colour change. I could confidently see and predict 3 months of work.

This report replaces the canvas-based chart I planned for series and milestones with a YUI 3 chart. The listing of bugs are split into categories so that I can focus on scheduling or provide Diogo with a list of bugs that need exploratory testing. Though this report thinks it is talking to Launchpad, it is actually using JSON for the 500+ bugs that I pulled using a trivial Launchpad API script. Since the data is cheap to retrieve, I can load the chart multiple times, each looking a different set of bug tags so that I can see specific themes of work.

The report shows that there is more than 60 days of work to complete the features needed by private projects. The Orange squad will work on private projects while the Purple squad finishes the prerequisites.

Some of us on the Launchpad team have been working on Ubuntu’s MAAS (Metal as a Service) over the past few months.

MAAS is all about giving your physical servers the flexibility and ease of deployment you’ve come to expect from the cloud. With MAAS your cluster of ten, one thousand or a hundred thousand servers becomes a single, reusable, pool of computing resource that you can pull up and tear down just like VMs in the cloud.

Tomorrow, Matthew from the Launchpad team is hosting a couple of webinars introducing MAAS. They’re both the same content but at different times.

We’re offering a unique opportunity to take part in one of the most exciting changes to affect the technology industry: the move to the cloud.

As Technical Writer in Canonical’s Launchpad team you’ll find the best way to ensure that users and developers of our software understand its benefits and how to use it. Whether it’s traditional documentation, screen casts or blog posts, you’ll find it easy to choose the right medium and you’ll have all the skills necessary to produce compelling, involving and effective content.

You’ll thrive in a rapidly changing environment where you’ll be expected to grasp new concepts quickly, develop an intimate understanding of three or four products simultaneously and determine the day to day shape of your own work.

A skilled writer, you’ll excel at finding the right information from your research and then communicating it with a casual confidence that puts people at ease and, most importantly, leaves them with the understanding they need to be effective.

Reporting to the team’s Product Manager, you’ll work as part of a fun-loving, highly skilled, global development team who produce tools including Launchpad, MAAS and Bazaar. You’ll share our love of hard work and our passion for free software, Ubuntu and the cloud.

Key responsibilities and accountabilities

Explain our products through traditional documentation, screencasts, podcasts and any other appropriate method.

Help ensure community and developer engagement with our platforms by documenting APIs and communicating the benefits of our various offerings.

Tell the story of the products we develop, through compelling blog posts and white papers.

Speak directly to the communities who use and develop our software in order to plan how you can best cater to their needs.

Required skills and experience

Your written English is well crafted, compelling and fun. You care about how you write, as much as what you write. You’ve produced end-user documentation, developer documentation, blog posts and white papers. What’s more, you enjoy doing it.

You have at least five years’ experience as technical writer, whether that’s professionally or as a consistent contributor to open source projects.

You’re smart: you find no problem in learning and owning a new concept.

When you speak, you find an instant rapport with your conversational partner or audience, and have no trouble in pitching your message appropriately.

When you listen, you ask all the right questions and can use the answers to create content that is appropriate to your audience and the information you need to communicate.

You live and breathe open source technology. You know the industry, understand the community and share the ideals. You know your OpenStack from your Intel, your ARM from your aaS and your Bugzilla from your Git.

You’re equally comfortable dealing with people in person, by phone, over email or using IRC and other remote communication tools.

You are willing to travel internationally, for periods of one or two weeks and occasionally longer, for conferences, developer-oriented meetings and sprints.

Desirable skills and experience

You’ve worked as part of team building cloud-related technologies or developer tools.

You use Ubuntu and are familiar with Launchpad and Bazaar.

You have a familiarity with one or more of the following:

IaaS platforms such as OpenStack, AWS, Eucalyptus

Ubuntu Server, particularly in cloud contexts

ARM server

distributed version control systems

a form of Linux packaging, such as .deb or .rpm

Python development

You have taken an active role in an open source software project and understand the dynamics, demands and constraints of working in a distributed community of volunteer and paid developers.

You’ve worked as part of a distributed team and can demonstrate the self-motivation and discipline required in such an environment.

Do you want to be one of the engineers building the infrastructure at the heart of the cloud revolution?

At Canonical we’re developing technologies that are key to the transition to the cloud, with Ubuntu as the number one cloud operating system. We are looking for a fun, talented software engineer whose ingenuity, self-motivation and engineering skill have contributed to a shining track record of successful projects.

Alongside four or five other engineers, you’ll be part of an agile engineering squad, in Canonical’s Launchpad team, working in either a new development or maintenance role on a different cloud-related project every six to nine months. Your work will touch projects such as OpenStack, MAAS, AWSome and the Launchpad SaaS developer tools platform.

To succeed you’ll need to share our love of hard work and our passion for free software, Ubuntu and the cloud.

Your energy and enthusiasm will be key to delivering the project, and to making the squad fun to be a part of.

Key Skills and Accountabilities

Develop new features in existing web or cloud applications or even start new ones from scratch.

Participate in the maintenance of the portfolio of applications maintained by the Launchpad team (a group of six development squads).

Collaborate within a small team of four to five engineers to design and deliver agreed features on an established schedule.

Ensure high quality results from across the team by participating in established team practices such as code review and testing.

Maintain readable developer-oriented documentation.

Coordinate regularly with the rest of the Launchpad team.

Required Skills and Experience

You have extensive experience in development of web applications using a major object or oriented application framework

You are proficient with the technologies powering the web such as Python, HTTP, HTML, CSS and JavaScript

You live and breathe open source technology. You know the industry, understand the community and share the ideals. You know your OpenStack from your intel, your ARM from your aaS and your Bugzilla from your Git

You are well experienced with at least one web application framework, such as Rails, Django, Zope/Plone, Pyramid, Turbogears, Web Objects, etc

You are well experienced with at least one JavaScript library/framework such as YUI 3/2, jQuery, Dojo, MooTools, or Prototype

You love easy to use software and pay particular attention to making your applications a joy to use

You have created stellar user interfaces using JavaScript, HTML and CSS

You’re skilled in object-oriented programming in the Python language

How people solve complex problems in software fascinates you. You also know that reliable and maintainable code are essential to long-term success. You’re familiar with writing about what needs to be done, as well as test-driven development and other “agile methods

You have strong spoken English communication skills, and can communicate clearly in writing, including email and IRC environments.

You have a good sense of humour and enjoy building a fun working environment with your colleagues.

You are willing to travel internationally, for periods of one or two weeks and occasionally longer, for conferences, developer-oriented meetings and sprints

Desired Skills and Experience

You are familiar with interaction design and have contributed to the user interface of a leading web application.

You have built and managed a community around an open source project

You have contributed code to an open source project

You understand the basics of one or more of the following:

laaS platforms such as OpenStack, AWS, Eucalyptus

Ubuntu Server, particularly in cloud contexts

ARM server

Services Oriented Architecture

Message-passing systems

Distributed version control systems

A form of Linux packaging, such as .deb or .rpm

You are familiar with Agile/Lean development practices

You enjoy exploring new languages like Go, Haskell or Clojure

You have system programming experience in C

You worked as part of a distributed software engineering team and can demonstrate the self-motivation and discipline required in such an environment

Apply online, or talk to us in #launchpad-dev if you want to see what we do!

Laura: What do you do on the Launchpad team?Martin: I’m on the newly created Blue squad, and we’re on the nebulous task of maintenance at present. I’m also on loan doing some juju development work.

Laura: Can we see something that you’ve worked on?Martin: You can see everything I’ve worked on. Well, all the things where I’ve had the convenience of using launchpad rather than having to send patches by email.

Laura: Where do you work?Martin: From home like most of the other developers in Canonical. I’m only a few hours away from the London office, but haven’t been there since the relocation.

Laura: What can you see from your office window?Martin: A weeping birch, and whatever feathered things perch atop. Sky, often blue, generally grey. Houses on the other side of the road. This time of year, swift acrobatics.

Laura: What did you do before working on the Launchpad team?Martin: Bazaar! Which is still a pretty key part of how Launchpad works. In between I worked on a cloud api proxy, which has sensibly been dropped in favour of just using the native openstack api.

Laura: What did you do before working at Canonical?Martin: Whatever came up, computer support and some development work.

Laura: How did you get into free software?Martin: Mostly from using it, having it break horribly, and getting the urge to make the code actually work.

Laura: What’s more important? Principle or pragmatism?Martin: Principle is more important, otherwise you compromise all the way to the other side. But you need some pragmatism to get anything done at all.

Laura: Do you/have you contribute(d) to any free software projects?Martin: I’ve tended to submit changes for anything I use heavily at the time, and to various bzr related projects. I’d use this space to hector some maintainer who’d been sitting on a patch for ages, but everyone’s been organised of late.

Laura: Tell us something really cool about Launchpad that not enough people know about.Martin: It actually works pretty well in lynx!

Laura: Is there anything in particular that you want to change in Launchpad?Martin: You mean apart from making it work better in lynx? I’d like bug search to suck less.

Laura: What do you do on the Launchpad team?
Vincent: Maintenance. Although I’m eagerly waiting for the sprint with gmb to get some hints on how to handle the beast In the mean time, I’m focusing on fixing bugs and making the udd importer more testable.

Laura: What can you see from your office window?
Vincent: The venerable Strasbourg post office, lovely old stones.

Laura: What did you do before working on the Launchpad team?
Vincent: Developing bzr.

Laura: What did you do before working at Canonical?
Vincent:Various service/consulting work for > 20 years, including some episodes at software editors.

Laura: How did you get into free software?Vincent: With pleasure

I think the most important event was in 1993: I encountered a blocking bug in g++ related to C++ templates (way before it was standardized). That was a roadblock, no work-around and it was Friday afternoon. In despair, I posted a reproducing case in the related newsgroup. When I came back to work on Monday I got an email telling me the bug was known *and* fixed *and* where to get the patch for the compiler.

That was a light-bulb instant: free software support could be far superior to commercial software support !

One week later, I got a second email asking me if I was out of trouble… Amazing, not only did I get a fix faster than I could have dreamed, but the guy *came back* to ensure I got it…

I never looked back.

Laura: What’s more important? Principle or pragmatism?
Vincent: Both are important. If you forget one, be prepared to pay the cost. Both are dangerous too if you forget the other:

- being pragmatic only most often means you’re adding to your tech debt or rely on others to finish your work,

- respecting principles excessively means you never deliver anything.

Laura: Do you/have you contribute(d) to any free software projects?
Vincent: bzr is my most important contributions (including a few plugins). I’ve occasionally sent patches to gtk, perl modules and various other bzr upstream projects.

Laura: Is there anything in particular that you want to change in Launchpad?
Vincent: Make it easier to test against for all projects that rely on it (I’m probably biased here as the udd importer severely suffer from not being able to properly test interactions with launchpad (read *and* write (branch creation mainly)).

Laura: What do you do on the Launchpad team?
Jelmer: I’m one of the blue haired freaks on the Launchpad blue squad, although my hair isn’t actually blue – I’m sure we can fix this at the next squad sprint. At the moment, we are working on maintenance: fixing
critical bugs in Launchpad and dealing with incidents.

Laura: Can we see something that you’ve worked on?Jelmer: I’ve contributed quite a bit to the code behind recipe builds. Most of my work has been on the backend though, not directly user-visible.

Laura: Where do you work?Jelmer: Like most of us I work at home, which in my case is in Utrecht, the Netherlands. Occasionally I cowork with other teleworkers in Utrecht.

Laura: What can you see from your office window?Jelmer: At the moment, I see just a big sad drapery made out of rain. On brighter days, I look out on a park and a canal.

Laura: What did you do before working on the Launchpad team?Jelmer: The Blue squad, which I’m currently in, was originally the Bazaar team. Before that, I worked on the Launchpad team too. This was back in the days when there were no squads, but teams – I was in the Soyuz team. The inimitable Matt Revell interviewed me back in 2010:

Laura: How did you get into free software?
Jelmer: A long time ago, in high school, I ended up maintaining a few server machines running FreeBSD and Samba. After hitting some bugs, a dive into the source code followed to see what I could fix. I’ve been involved with various free software projects ever since.

Laura: What’s more important? Principle or pragmatism?Jelmer: Do I really have to choose? That’s not very pragmatic.

Laura: Do you/have you contribute(d) to any free software projects?
Jelmer: Beside Launchpad, the main free software project I am involved in is Samba. There are several other projects that I have made major contributions to, such as Bazaar, CUPS, Wireshark, OpenChange, BitlBee.

I’m a Debian maintainer and Ubuntu uploader, mostly for projects I am involved in upstream. This knowledge comes in handy when working on the archive side of Launchpad.

Laura: Tell us something really cool about Launchpad that not enough people know about.
Jelmer: https://launchpad.net/builders lists all the Launchpad builders and
the mischief they are up to.

Laura: Is there anything in particular that you want to change in Launchpad?Jelmer: It would still be really nice to have dashboards of some kind in
Launchpad. There is even a LEP.

We want the project maintainer to be the default party that the project shares private information with. The problem at the moment is that Launchpad does not know how to set a team as the project maintainer during setup. Improper project setup is the root cause of most cases where information is disclosed to the wrong people. We need to improve project registration and setup to ensure users can ensure private information is managed properly. This issue is complicated by a very old issue, it is not possible to register a team at the moment you discover you need one. Launchpad must let me register a new team that will maintain my project when I first setup my project.

The Purple Squad discussed what we can do to simplify team registration and perform the registration in any page that allows you to set a team. We discovered several areas where we can make improvements.

Do not ask for non-essential information like contact address.

We can simplify the team membership policy language.

We can fix the confusion about membership renewal.

Launchpad can pre-fill the form with sensible defaults when the team will be used in a role.

Ian put together a demonstration to prove we could extend the person picker to also permit you to register a team.

When you want to set the project maintainer to a new team, Launchpad will ask you to confirm its suggestions for the Launchpad Id, display name, and membership policy. You can change the values, but most of the time you will choose to continue, and Launchpad will register the team and place it in the role.

When I ran the Launchpad Development Clinics at the last UDS, I was asked if I would give a presentation on how to fix a simple bug in Launchpad. This sounded like a great idea – after all there’s a lot of parts to the Launchpad development process that apply to every single branch you ever write, so it seemed well worth the effort. Rather than a presentation, though, I figured a screencast would be of more use, so here is just such a screencast. If you’ve got any questions or comments, don’t hesitate to get in touch.

Laura: What do you do on the Launchpad team?
John: I’m the team lead for the Blue squad. Right now our squad is on Maintenance, so I generally do the coordination work of our team with other teams and the system administrators.

Laura: Can we see something that you’ve worked on?John: Before we switched to maintenance, our team was focusing on doing Bazaar work. Within the more recent time, we’ve done stuff like fixing up the Ubuntu Distributed Development package importer, and getting translations for Quantal started for Launchpad.

Laura:Where do you work?
John: I work from home in the Netherlands.

Laura: What can you see from your office window?
John: We have a forest near our house, and some of the other neighbors houses.

Laura: What did you do before working on the Launchpad team?John: As mentioned, we were focused on development of Bazaar, though arguably that was still part of the Launchpad group (not officially, but in spirit).

Laura: What did you do before working at Canonical?
John: I worked for a company developing medical imaging algorithms, mostly for detection and visualization of disease.

Laura: How did you get into free software?
John: Our team wanted to use something better than CVS for development. At the time SVN was pretty hard to set up, and there was just the beginnings of a couple of tools for distributed version control. I got into tla at the beginning, and was happy when Canonical started Bazaar, and I was able to hack on it.

Laura: What’s more important? Principle or pragmatism?John: I’m a fairly pragmatic engineer. I think it is good to use principle as a guideline, but in the end if the work isn’t in the hands of people using it, it is providing no benefit and is arguably wasted effort.

Laura: Do you/have you contribute(d) to any free software projects?
John: Well, Launchpad and Bazaar are both pretty clear things (and tla a little bit before that). I also developed some other tools while here at Canonical. Such as Meliae for profiling python memory.

Laura: Tell us something really cool about Launchpad that not enough people know about.
John: The UDD package importer turns the changes from debian packages into real VCS branches that you can do lots of nice stuff on. (annotate the history, log the history, see the graph over time, etc.)

I think we are at about 90% coverage, and you can do “bzr log ubuntu:package” to find out the recent history for a package in ubuntu.

Laura: Is there anything in particular that you want to change in Launchpad?
John: My own personal project with launchpad is improving the connection handling when accessing Bazaar branches. Right now it is approximately 3s just to do the ssh handshake and start talking to codehosting. I have some improvements that should decrease that significantly, but we encounter some strange hanging bugs that are only reproducible in production. And LP’s commitment to having minimal user-visible downtime is particularly problematic for SSH connections. A single HTTP request is less than 5s, but an SSH connection can legitimately be active for an hour if accessing a large project.

All users can now see the information type section that replaces the privacy and security section shown on bug and branch pages. This change allows users to clearly state the kind of information a bug or branch contains. Launchpad will soon permit project maintainers to share information types instead of managing individual bug and branch subscriptions. Project maintainers can see a link on their project’s front page to the ”Sharing” page. Sharing lists all the users and teams their project shares some private bugs and branches with. This list might be surprising. Launchpad Beta testers will soon be able share and unshare kinds of information to simplify management of whom the project discloses private information to.

The Purple Squad recently discussed how the forthcoming sharing feature changes project setup. Sharing will allow project maintainers to share kinds of information with users and team. This feature separates access to private information from bug and branch subscriptions. Maintainers do not need to manage hundreds of subscriptions, users do not needs to block unwanted email.

Before sharing, direct subscriptions were the only way Launchpad knew which users the bug or branch was disclosed to. Launchpad would subscribe the maintainer, or the team in a designated role to ensure someone could work with the information in the bug or branch. The subscribed users would then be responsible for subscribing other users and team so that everyone who needs to know about the information could work with it. Most users subscribed to private bugs and branches get unsolicited email. Each user’s project, series, and milestone subscriptions are ignored.

After sharing, subscriptions to projects, series, and milestones will just work. If a private bug matches your project subscriptions, and that kind of information is shared with you, you will get the email. You will be able to subscribe to kinds of information, such as embargoed security.

The security contact role

The security contact role is obsoleted by sharing. It can be removed.

The security contact exists to tell Launchpad which team to subscribe to embargoed security bugs to ensure the information is disclosed to someone. The role does not convey any other privileges. Only one team could be in the role; it was not possible to tell Launchpad that embargoed security bugs should be disclosed to several teams. Sharing allows the maintainer to specify which teams embargoed security information is disclosed to.

The bug listing page implies that no one has access to security information when the role is not set. This was never the case. Launchpad subscribed the maintainer to the bug if no one was in the security contact role. Maybe Launchpad should show a notice to maintainers when it detects that no one is subscribed to get security mail? This presumes email is how users want to be notified. It think this is nice to have, but not a requirement. I would prefer Launchpad to present a log of recent activity on its pages and send me emails that summarise important activity when I have not visited the pages recently.

The bug supervisor role

The bug supervisor looses its private bug responsibilities after sharing. It is still useful to delegated additional bug editing privileges to a team who does not drive development decisions.

The bug supervisor role will be used less often. Most teams currently in the bug supervisor role are also in the driver or maintainer role. Launchpad required maintainers to set the bug supervisor role to ensure that those that plan released can also see the private bugs. Small projects will not need the role. It will only be needed by projects that want to expand the number of contributor who can triage bugs without expanding the number of people who do release management.

The maintainer role

The maintainer role is unchanged by sharing. Well, it responsibilities are unchanged, so we must ensure that the project shares private information with the maintainer by default.

When a project is registered, Launchpad must share each kind of private information with the maintainer. This is rule is not as simple as you might think. Many projects are registered by a user, who sets a team as the maintainer during setup. From Launchpad’s perspective, the project has transferred the role. Launchpad does not know what to do [1]. Some maintainers do not want to work with private information, they delegate to other teams. Launchpad cannot presume that changing the maintainer means changing who private information is disclosed to. Maintainers can always choose to share the information with themselves.

Launchpad’s project setup workflow is incomplete. There are two screens that gather the basic information, but you can set additional information on the project front page. There are five pages to configure how the project uses Launchpad that maintainers should review during setup, but we did not have the time integrate them. We do not want users to do more work. Instead we want Launchpad to present just the essential information and have sensible defaults.

Reimaging/completing project setup is out of scope for the sharing feature, but it might be in scope for the Purple Squads next feature, private projects. During setup, Launchpad needs to know who the maintainer will be and share private information with them. We can consider this work as an enhancement to maintain expected behaviour. We will do this work as a part of the sharing feature. When we work on private projects, we can explore what else project setup and reconfigure needs to do to ensure that information is disclosed to the proper teams. Private projects will also entail making projects public, which means reconfiguring the kinds of information a project has.

[1] If you have ever changed the bug supervisor or security contact, you might know of the pain I am alluding to. Bang head against desk, scream at computer, weep, set aside a few weeks of your valuable time to update all bug subscriptions yourself so that the new team can do it’s job. This whole scenario is implicitly fixed by sharing since subscriptions are not used to manage access.

The Launchpad team is planning a new feature that will allow you to link bugs to each other and describe their relationship. The general idea is that you can say one bug depends of the fix of another. The goal is to make it clear where conversations to fix issues take place, who will do the work, and when the work can start.

Managing bug relationships

Organisations and communities split issues into separate bugs when different people work at different times with different priorities to solve the bigger issue. Organisations and communities merge bugs when they want a single conversation to fix an issue that affects several projects at a single time. Explicit relationship between bugs (or the many projects listed on a single bug) would help projects organise work.

There are four general relationships that people try to describe when working to fix an issue. These relationship are either explicit, or implied when a bug affects multiple projects, or many bugs affect a single project. The relationship informs everyone about where the conversation to fix an issue happens, and the order of work to fix a group of issues.

Duplicate: Bug X is the same as bug Y. The primary conversation about fixing the bug happens on bug Y. A secondary conversation happen on bug X. The affected projects, their status and importance, of bug X are identical to Bug Y.

Dependency: Bug X depends on bug Y. Bug Y must be fixed before bug X can be fixed. The bugs have separate conversations, but each is informed of the other. Though the bugs have separate status and importance, there is some expectation that work proceeds from one bug to the next. As the bugs might affect different projects, the work to fix a bug may be done by different people. A project bug might depend on the fix in a library that is provided by another project. A bug in a distro series package might depend on the fix in an upstream project release. Dependency is implied when we see a bug that affects a distro package also affects the package’s upstream project.

Similarity: Bug X and bug Y are caused by similar implementations. Bug X and Y require separate fixes that can happen concurrently. The bugs might share a conversation to find a fix, but the work and conversation is more often independent. In some cases, the proper fix is to create one implementation that the similar bugs depend on to fix the issue. A project might have two bugs caused by a bad pattern repeated in the code, or a pattern in one project is also used by another project. Each location of the pattern needs fixing. Maybe the right fix is to have a single implementation instead of multiple implementations.

overlap: Fixing bug X changes the scope of work to fix bug Y. These bugs have separate conversations, but the work to fix each issue needs coordination. Fixing one bug may make the other invalid, or make it more difficult to fix the other. Maybe these bugs need to be redefined so that they do not overlap? Maybe bug X can be fixed at the same time as bug Y? Maybe both bugs really depend on an unknown root cause…bug Z?

We might imagine the relationships like sets. The duplicate bug is a subset of the master bug. Two bugs intersect in the overlap relationship. Similarity is a superset of several bugs. The dependency relationship has a direction pointing from one bug to the next.

Managing separate conversations

People working with proprietary information create duplicate and or dependent bugs to manage separate conversations. The “Affect project”, “Affects distro”, and “Duplicate” action do not work because they either mix conversations, or loose status and importance. Users benefit when private conversations are split from public ones, but Launchpad does not help the user do this.

Launchpad will not permit projects to share the forthcoming “proprietary” bug information type. Proprietary information is given to one project in confidence; The project cannot share that information with another project. The ”Affects project”, “Affects distro” cannot add projects to the bug, so Launchpad must help users report a separate bugs.

When someone realises a private bug affects more than one project, Launchpad could help the user split the bug into separate bug reports to manage conversations and the order of work to fix the greater issue. Instead of adding a project or distro to the bug, the user might want to choose the project to report the bug in, and be prompted to revise the bug summary and description so that private information is not disclosed. The new bug is commonly public. It is the master bug, this is where the public conversation happens. This practice benefits more than the user who reported the bug…there is a public place for all users to discuss the issue.

Users are less likely to report a duplicate bug when Launchpad can show the public bug in the list of similar bugs. The principal cause of bug 434733 is not commercial projects, bug non-commercial projects like Ubuntu that mark bugs as duplicates of private bugs without consideration that users want to be informed and participate in the conversation.

Duplicate bugs continue to have separate side conversations that often focus on release issues. The discussion of how to fix the issue happens on the master bug. Duplicate bugs also have wasteful conversations that can be answered by the master bug. There is always a risk of disclosure when the reporter of a private bug has to visit the public bug to learn information that is pertinent to the private bug. The risk and inconvenience could be avoided by showing the important information on the duplicate bug — do not force users to change the context when working with private data.

We can substitute another relationship for “duplicate” in my case for separating discussions. When a fix for a bug is dependent on a one or more other bug fixes, there are several conversations with different people with different concerns. The same is true for bugs with similar or overlapping concerns. The only time conversations really need to be shared is to coordinate the timing or scope of the fixes.

While privacy is a primary reason to split conversations, splitting public conversations can benefit as well. The current UI that encourages a single conversation of ambiguously related downstream and upstream projects is a source of unwanted email. If I am only interested in the issues that affect my projects, do not make be get email for all the other projects. Splitting conversations into several bugs within a project is also a legitimate means to solve large problems that require different developers to fix code at different times. Minimising the notifications to just the relevant information keeps users focused on the issues.

Linking existing bugs

The workflow to select and link bugs is untrusted. When marking a bug as a duplicate, or linking a bug to a branch, Launchpad asks me to provide the bug number (Launchpad Id), then the page updates and I learn the consequences. Did I type the right number? Did people get emails about irrelevant or confidential information?

I expect Launchpad to ask me to review the bug I am linking and ask me to continue or cancel. Launchpad has to show enough information to answer my question’s and gain my trust:

What is the bug’s summary?

What is bug’s information type — is it private?

Which projects does the bug affect?

What are the bug’s tags?

What is the bug’s description?

The presentation for bug listings provides most of this information. Launchpad could reuse the presentation (that I am already familiar with) when asking me to review the bug that matched the number I entered.

I imagine that if the action I am taking is specific, like marking a bug as a duplicate of another, Launchpad does not need to ask me about the relationship. In cases where the relationship is not implicit in the action, Launchpad must let me select the relationship between the bugs.

I know many users expect bug linking to work like selecting a user. They want to enter search criteria to see a listing of matches. The user might expand a match to see additional information. The user can select the bug, and maybe select the relationship to create the link. I am sceptical that this workflow would meet my needs. I often use advanced bug search to locate a bug; I cannot imagine offering advanced bug search in the small space to select a bug to link. The picker infrastructure that provides the workflows to select users and projects supports filters, which could be adapted to work with bug tags. I doubt this will be very useful. Advanced bug search does not work well across multiple projects, and bug linking does and must work across projects. I think people will still needs to use advanced search to locate the bug that they want to link.

Presenting a summary of the bug relationships

When an issue is represented by several bugs, or a bug affects several projects, users need known how they relate to understand where and when someone needs to take action. Users often open many pages because Launchpad cannot summarise the relationships between several bugs. Users will also read through long comments to learn why a bug affects many projects.

When viewing a bug, the user needs to see a listing of related bugs (dependency, similarity, and overlap). The listing summarises the affected project, status, importance, assignee, and milestone. Users might need to see bug tags, and badges for branches and patches. Maybe this is like the listing of bugs shown in bug search.

The affects table is a special bug listing. Does it need to be special? Users want to see the relationship between the items in the affects table. I want to know if the fix in a package depends on the fix in an upstream project. I am unsure how this could be done since there might be many relationships in the table. Maybe the many relationships, 3 or more affected project, packages, and series, will diminish when bug linking is available. We know that users unsubscribe when a bug affects many things because the conversation looses focus. When users can link bugs, there will be less needs to say a bug affects many things.

Privacy is a special case. A user can only see the relationship between two bugs if the user can see both bugs. When the listing contains private bugs, the presentation must call-out that they are seeing privileged information. Launchpad does not have a consistent way to show that part of a page contains private information.

The user profile page will show locks before email addresses.

Bug listings show a lock icon among other icons after the bug.

Branch listings and linked branches show the lock icon after the branch.

Launchpad must make it clear to the user to not discuss the private relationships in the bug’s conversation.

Duplicates are presented differently from other bugs because they are subordinate to the master bug. There are several problems with the current presentation of duplicate bugs.

Duplicate bugs show contradictory information in the affects table

Duplicate bugs may not show the master bug if it is private

Master bugs may show hundreds of duplicate bug numbers without summary or privacy information

Why do I need to see all the duplicate bug numbers on a master bug?

Users do not need to see a list of all the duplicate bugs on the master bug. The number of duplicates is more interesting that a listing of numbers. User care about the duplicates they reported because they might want a side conversation, maybe Launchpad should show the user a link to the bug he or she reported? A contributor might want to read the the conversations in the duplicates for new information, so Launchpad does need to show a list of duplicates when the user asks for it. The listing of duplicates must indicate which are private. Other data like status and importance are irrelevant because the master bug provides the this information.

When I view a duplicate bug page, Launchpad must make it clear that this bug is a duplicate. I need to see the master bug’s information: affected project, importance, status, milestone, and assignee. I am not sure if the user should see its own affects table; that information would only be important if the bug was unduplicated.

There is a problem if the master bug is private and the user does not have permission to see the master bug. The user cannot see the master bug exists. Launchpad could prevent duplicate master bugs from being private if the project can have public bugs. In the case of projects with default proprietary bugs, the master bug will always be private. When the reporter of the duplicate bug cannot get information, he, and the project contributors are forced to start side conversations. Is it possible to show some of the affects table from the master bug to answer some of the user’s questions? May I know the status and importance of the master bug? May I know the affected project if both bugs have the same affected project?

Conclusion

The Launchpad team will spend about 12 weeks creating the bug linking feature. The feature will emphasise the use cases needed to support two other features in development now, sharing and private projects. Proprietary data has less need for revising the bug affects table, though a unified presentation of linked bug and affects projects might need less effort to create.

The essential points about bug linking is that project needs to manage bug conversations to mange the disclosure of private information. Organisations split work into multiple bugs to mange conversations and organise work between different people. Launchpad could show and summarise the linked bugs so that contributors do not need to switch context to plan work.

I think Launchpad is missing fundamental HTML, CSS, and JavaScript to support the three classes of browser with which someone might visit Launchpad. There are inconsistencies in pages you might visit, and some parts might not work because Launchpad does not have a “proven way” to solve a problem. I am most concerned about the rules of when something should be shown or hidden.

Launchpad intends to look good in graphical browsers, and gracefully degrade for textual browsers. Launchpad intends to be usable by everyone, and interactive browsers get enhanced features that makes the site easier to work with. We expect everyone who works with Launchpad regularly to use an interactive browser which provides information as needed and the best performance to complete a task. Essential tasks must be performable by textual browsers.

The three classes of browser Launchpad developers need to design for

Textual browsers convey all information with text, layout is less important and graphics are irrelevant. Textual browsers might be text-based browsers like W3m or Lynx, or it might be a screen-reader like Orca with a graphical browser. Textual browsers can also be bots, or even the test browser used by Launchpad’s test suite. All essential information must be expressible as text.

Graphical browsers use CSS-based engines to layout text and graphics in two dimensions. Chromium and Firefox are two of many browsers that might be used. Launchpad wants to use CSS 3, but it cannot be required since some browsers like Internet Explorer 8 use CSS 2. There is also the concern that all browsers have CSS and HTML bugs that require some care when crafting a page.

Interactive browsers support JavaScript to change the page content based on user actions. Again, Chromium and Firefox are two of many browsers that might be used, but a minority of users choose to use platform browsers like Internet Explorer, Safari, or Konqueror. Launchpad wants to use EcmaScript level 5, but will accept ES 3 with proper design.

Showing the essential, offering the optional, and hiding the unneeded

Consider the case for reporting a bug. This is an essential task everyone must be able to perform with the browser that they have available. Some steps in reporting a bug are optional, and might even be considered a distraction. Reporting a bug can take many minutes, but it can be made faster by showing or updating information at the moment of need.

Launchpad commonly makes links to add/report something like this:

<a class="sprite add" href="+action"></a>

The markup relies on CSS to show an icon in the background of the space allocated to the link. There is no text to convey the action is “Report a bug”. We have struggled to make this markup work in all browsers. I personally do not think this markup is legal. Anchors may be empty because they can have name attributes without href attributes. The HTML specification does not state an empty anchor with a href must be rendered. Older versions of webkit and khtml certainly do not render the sprite because there is no content to show. This markup is missing a description of what the link does.

Launchpad makes some links for its test browser that just happen to work brilliantly with textual browsers:

Graphical browsers see an icon, and textual browsers see text. Well, this is not exactly true. Older webkit browsers do not show text or icon because there is no text to render. We use JavaScript to add an additional CSS class to the page so that a special CSS rules can add content before the hidden text to make the link visible. The “invisible-link” name is bad though, we do want the link visible, we just want a icon shown when the browser supports it. Like the previous example, graphical browsers still do not see a description of what the link does.

Launchpad commonly uses expanders to hide and show optional content. The blocks look something like this:

Textual browsers can read the hidden content; they can set bug tags. Interactive browsers see “Options” and can reveal the content to set bug tags. Graphical browsers (or a browser where JavaScript failed) just see “Options”, it is not possible to set bug tags. The “unseen” CSS class could have been added after the script executed in the interactive browser to ensure it was hidden only if the browser could reveal it.

Launchpad does not have classes that distinguish between interactive content that is “unseen” and graphical content that is “unseen”. The first line means interactive browsers cannot see the input element, and the second line means graphical browsers cannot see the img element. This ambiguity leads to cases where content that should be seen is missing, or vice versa.

Launchpad needs classes that mean what we intend

I image four classes are need to handle the cases for the three classes of browser.

readable

Textual browser can read or speak the content.
Graphical and interactive browsers to not show the content.
eg. links with sprites.

enhanceable

Textual and Graphical browsers can read, speak, and see the content.
Interactive browsers do not show the content, but can reveal it.
eg. expanders that show additional information or optional fields.

replaceable

Textual and Graphical browsers can read, speak, and see the content.
Interactive browsers do not see the content because it is superseded.
eg. forms that reload the page.

revealable

Textual and graphical browsers cannot read, speak, or see the content.
Interactive browsers do not show the content, but can reveal it.
eg. spinners that show loading in-page content.

The CSS classes need to interact with other classes on the page that help identify the class of browser:

readable

May need aural CSS to ensure it can be read and spoken.

enhanceable

No special properties needed.

enhanceable hidden

Scripts add the hidden class at the end of a successful setup because the content can be shown.

enhanceable shown

Scripts add the shown class at the end of a successful setup because the content can be hidden.

replaceable

No special properties needed.

replaceable hidden

Scripts add the hidden class at the end of of a successful setup because the content was replaced by interactive content.

revealable

The is not displayed because the browser must prove it can interact with it.

revealable shown

Scripts add the shown class at the end of a successful setup because the browser has demonstrated it can interact with the content.

Both the single “enhanceable” and “revealable” could be omitted because they are redundant with “enhanceable shown” and “revealable hidden”. I think the habit of placing classes that hide and show content in the page templates is dangerous. There are lots of cases where the page assumes a state before the class of browser is known. Page templates that use either “unseen”, or the ”hidden” class assume an interactive browser. It is not clear if textual and graphical browsers work by design, or by accident.

You’ll remember that a while back, dear reader, we announced that we’d be running a couple of Launchpad Development Clinics at UDS (we called them Launchpad Clinics at the time, and I lost count of how many people commented that that sounded as though Launchpad was ill. It isn’t; it’s in the same rude health that it always was). We’ll come up with a better name next year!

Anyway, we made the announcement, put up the wiki page, saw a few names and bugs added to it, and didn’t really expect to be hugely busy. Indeed, when Laura, Matthew, Huw, Raphaël and I convened in one of the UDS meeting rooms for the first clinic, it was mostly empty except for the stragglers from the previous session.

Then a person appeared. Actually, it was two people squeezed into the skin of one person: Tim Penhey, who looks like he’s been chiseled out of granite and has a tendency to loom well-meaningly, like an avuncular greek pillar. We figured that since he’s an ex-Launchpadder, he didn’t count, and so went back to self-deprecatory joking whilst worrying that we’d massively miscalculated how many people would want to come to the clinics.

And then another person arrived. And another, and another. Soon, we’d gone from having a couple of attendees who really just needed to run ideas past a Launchpad core developer to having ten people who all needed questions answered, or a development instance spun up. After that, things get a bit fuzzy, because I was always answering someone’s question or being root on an EC2 instance for someone else. When Laura told us that our time was up I was, I have to confess, somewhat surprised.

Thursday’s session was a quieter affair, in part at least because we had to reschedule it at the last minute (UDS schedules are like quicksand, and if it weren’t for the amazing UDS admin team everyone would be thoroughly lost for much of the time), but there were still people there with bugs to be fixed and questions to be answered. I had preliminary discussions with Chris Johnston about adding API support to Blueprints, and worked with Ursula Junque on working out how to add activity logging to the same.

The upshot of the clinics is, I think, massively positive. There is a genuine development community out there for Launchpad, and people really are keen to make changes to the dear old Beast whilst the Launchpad core developers are working elsewhere or fixing things that are horribly complex (and usually not user-facing). For someone like me, who had been somewhat skeptical about the kind of response the clinics would receive (even though they were partly my idea), this is immensely gratifying news.

There are, of course, many things that we need to improve on, and many lessons that we can learn. People want to know how to fix a simple bug without having to come to a session at UDS, so I’m going to record a screencast of just such a procedure, right from finding the bug to working out where the fix lives, all the way through the coding and testing process, right up to the point of getting the branch reviewed and landed. Hopefully this will give everyone a great jumping-off point.

When we set out on this particular journey, one of the criteria I wrote down for considering the clinics a success was “we’ll want to do it again at the next UDS.” Well, I do. We did well; we can and will do better next time. Who’s with me?

The Launchpad team is planning a new feature that will allow you to link bugs to each other and describe their relationship. The general idea is that you can say one bug depends of the fix of another.

We’ll be asking you to help us decide the scope of this feature, so look out for invitations to user research sessions over the coming weeks if you’d like to get involved.

Key Issues

There are issues about the kinds of relationship that should be supported and the types of workflows to use them. Before I describe the workflows and relationships that we have discussed, I think I should first write about the existing bug linking features and hacks.

Affects Project or Package

Launchpad has always recognised that a bug can affect many projects and packages. Launchpad defines a bug as an issue that has a conversation. The information in the conversation is commonly public, but it might be private because it contains security, proprietary or personal information. An issue can affect one or more projects and packages, and each will track its own progress to close the bug.

A bug in a package often originates in the upstream project’s code. I assume that when I see a project and a package listed in the same bug that there is an upstream relationship, but that is not always the case. So some bugs affect multiple packages and projects? How do I interpret this? Maybe one project is a library used by other projects. Maybe the projects and packages cargo-cult broken code that require independent fixes. Maybe the code from one project is included in the source tree of other projects. When I look at the table of affected projects and packages on a bug, I have to guess how they relate. I don’t know if fixes happen in a sequence, or at the same time as each other. Is one project fixed automatically by a fix in another project?

Contributors from all the affected projects contribute to the conversation. The conversation can be hard to read when several projects are discussing their own solution. It is common for everyone from one project to unsubscribe from a bug when the project marks the bug as fixed. This is a case were users are still getting bug mail about an issue that is fixed for them. Maybe there’s more than one issue if there’s more than one conversation happening?

Duplicate

Users commonly report bugs that are duplicates of other bugs. Marking a bug a duplicate of another means that the conversation and progress about an issue is happening somewhere else.

It is common for duplicate bugs to affect different projects from the master bug. Was the duplicate wrong, or maybe Launchpad did not add the duplicate’s affected projects to the master bug’s affected projects?

I can mark your bug to be a duplicate of a bug that you can’t see (because it is private). This is very bad. If I do this, you cannot participate in the conversation to fix the bug, and you don’t know when the bug will be fixed. It is common practice to make the first reported occurrence of a bug the master of all the duplicates, but if the first occurrence has personal information in it, it probably cannot ever be public. Thoughtful users create public versions of bugs and make them the masters of the duplicates so that everyone can participate and be informed.

Links in Comments

Launchpad automatically links text that appears to be a bug number. A user can add a comment about another bug and any user can follow the link to see the bug.

There are many kinds of relationships described in comments which contain linked bugs: “B might be a duplicate of C”, “D must be fixed before E”, “F overlaps with G”, “H invalidates J”, “K is the same area of code as L”, “M is the master issue of N”. I cannot see the status of the linked bugs without opening the bug. Maybe the bug was marked invalid or fixed? Bug comments cannot be edited, so the links in the comments might be historic cruft.

Bug Tags

Bug tags allow projects to classify the themes described and implied in a bug. Projects can use many tags to state how a bug relates to a problem domain, a component, a subsystem, a feature, or an estimate of complexity. Launchpad does not impose an order upon bug tags.

Some projects repurpose/subvert bug tags to describe a relationship between two or more bugs. The tag might describe a relationship and master bug number, such as “dependent-on-123456″ and a handful of bugs will use it. Multiple tags might be used on one bug to describe all the directions of the relationships. A search for the tag will show the related bugs and you can see their status, importances, and assignee. The tag becomes obsolete when all all its bugs are closed. There might be more obsolete bug tags then operational ones. Bug numbers embedded in the tags are not updated if one bug becomes the duplicate of another.

Bug Watches

Bug watches sync the status and comments of a bug in a remote bug tracker to Launchpad. Projects can state that the root cause of a problem is in another project, and that project uses another bug tracker. The bug watch is presented in the bug affects table as a separate row so that users can see the remote information with the Launchpad information.

When the bug watch reports the bug is fixed, the other projects can then prepare their fixes based on the watched project’s changes. Since the information is shown in the bug affects table, it has all the same relationship problems previously described. I do not know if I need to get the latest release from the watch project, or create patch, or do nothing. Launchpad interleaves the comments from the remote bug tracker with the Launchpad bug comments, which means there is more than one conversation happening. The UI does distinguish between the comments, but it is not always clear that there are two conversations in the UI and in email.

Next

Launchpad beta testers are seeing information types on bug reports. Launchpad replaced the private and security checkboxes with an information type chooser. The information types determine who may know about the bug.

When you report a bug, you can choose the information type that describes the bug’s content. The person who triages the bug may change the information type. Information types may also change as a part of a workflow, for example, a bug may start as Embargoed Security while the bug is being fixed, then the release manager can change the information type to Unembargoed Security after the release.

Testing in phases

In the first phase of this beta, Launchpad continues to share private information with bug supervisors and security contacts using bug subscriptions. The project maintainer may be managing hundreds of bug subscriptions to private bugs, and people are getting unwanted bug mail.

In the second phase of the beta, the project maintainer can share information types with people…the maintainer is only managing shares with a few teams and users and people are not getting unwanted bug mail.

Watch the video of information types and sharing to see the feature in use and hints of the future.

This is a huge milestone for everyone that uses and contributes to Launchpad and serves as a great witness to all the achievements, trials and challenges we’ve faced over the past 7 years. Today’s post is made up of contributions from some of the people who’ve worked with Launchpad and on developing Launchpad itself, right from the very start, up until fairly recently, like myself.

We’d love to hear your thoughts and experiences too, so please add a comment at the end if you have a story to share.

Francis Lacoste – Launchpad Manager
“Launchpad is vast. The significant milestones reached could be quite varied. But to me, the most important ones are the ones that enabled a community to use Launchpad for new activities. Thus, the first milestone was in the very earliest days, when the Ubuntu community switched from Bugzilla to Launchpad for tracking Ubuntu bugs!

“Other important milestones were when bzr and Launchpad code hosting were fast enough to host the huge Launchpad source tree itself (back in 2007). Then in 2008, when Launchpad started using Launchpad for code reviews! Other significant milestones were when MySQL joined Launchpad and bzr also in 2008. This opened the door for other big communities to join Launchpad: drizzle and then OpenStack. Finally, more recent milestones of this sort were when we introduced source package branches and Ubuntu started importing all of their packages in bzr: https://code.launchpad.net/ubuntu

“Last year, we introduced derived distributions which is now being used to synchronize with Debian development versions.”

Matthew Revell – Launchpad Product Manager
“There’s so much in Launchpad that it’s almost impossible to settle on a particular highlight. However, PPAs stick out as something of a game-changer. Someone once said that the cool thing about apt isn’t so much apt, but actually the software archive behind it. I love that I can trust the Ubuntu archive to give me what I need in a reliable form.

“However, PPAs have helped bring greater diversity to Ubuntu by allowing anyone to build and publish their own packages in their own apt repository. With the addition of private PPAs and package branches, we have probably the best combination of centralised repos and software from elsewhere that I’ve seen in any operating system.”

Graham Binns – Software Engineer, Launchpad
“Probably the most significant moment for me over the time I’ve worked on Launchpad was its open-sourcing. Suddenly, this big beast that we’d worked on for years was open to outside contributions, and that was and still is incredibly exciting to me.”

Laura Czajkowski – Launchpad Support Specialist
“I think the best thing I’ve seen in a long time on Launchpad was the set downtime and reduced downtime that happens each day. This minimises the effect for all projects hosted on launchpad an many people never even notice it down.”

J.C.Sackett – Software Engineer, Launchpad
“When I started on launchpad, the volume of bug data was a source of constant performance problems. Our 1 millionth bug is noteworthy in that we’re handling 1 million bugs better now than we were handling 500,000 then.”

Curtis Hovey – Launchpad Squad Lead
“Launchpad’s recipes rock. They allow projects to automatically publish packages created from the latest commits to their branch. Users can test the latest fixes and features hours after a developer commits the work.”

Diogo Matsubara – QA Engineer
“Personal package archives combined with source package recipes allows any Launchpad user to easily put their software into Ubuntu and this is a pretty unique feature from Launchpad.”

Tom Ellis – Premium Service Engineer
“It’s been great to see Launchpad grow and scale. A key milestone for me was seeing Launchpad move from a system that was not scaling well to one which has been a great example of continuous development and seeing the web UI improve in usability.”