Project maintainers can see private bugs
Published by Curtis Hovey July 23, 2012 in General
Project maintainers can now see all the private bugs in their project. While Launchpad tried to ensure the proper people could see private bugs in the past, the old subscription mechanism was brittle. Users could unsubscribe themselves and lose access, or retarget a bug to another projects which does not update bug subscriptions. The Purple squad migrated project configurations to project sharing so that all private information was shared with project maintainers. Project sharing ensures that confidential information is disclosed to the proper people.
If you are a project maintainer, you might be surprised to find old private bugs that you have never seen before. This happened to me. Some ancient private bugs were in the “New” listing of bugs, other were buried in search results. You can search for just private bugs to review all private bugs.
Privacy terminology is restored
We reverted the information type terminology changes introduced a few months ago.
- User data ➙ Private
- Embargoed Security ➙ Private Security
- Unembargoed Security ➙ Public Security
While the jargon-laden terms helped the small number of people who work with confidential information, the people who report bugs were confused. The most common reason for unwanted disclosure is that people enter confidential information, and cannot see how to make it private. Sometimes a user may not notice the mistake until a few minutes later. We also revised the descriptions of the information types to help new users quickly select the correct information type.
You can hide your bug and question comments
Published by Curtis Hovey in General
You can now hide your own bug and question comments. If you want to hide a comment made in error, you can use the “Hide comment” action.
You can see it, and even unhide it if you choose. The project’s maintainer or the trusted people delegated to work with private information can still see your comment.
This allows you, or the people the project shares private information with, to hide just the comments that contain personal information. The bug does not need to be made private if the comment can be hidden. Project maintainers can also hide comments because they contain spam or abuse.
Beta test: asynchronous PPA package copies
Published by Colin Watson July 18, 2012 in General
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.
Bug reporting and search knows about privacy
Published by Curtis Hovey July 16, 2012 in General
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.
- Project maintainers, drivers, and bug supervisors can report private bugs.
- Autocomplete works with bug tags
- The status and importance controls show their definitions.
- 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.
- You can use the tab key to move between the items in popups.
- You cannot accidentally tab out of any popup.
Launchpad does not have private projects…yet.
Published by Curtis Hovey July 13, 2012 in General
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.
Webinar on Ubuntu MAAS: Metal as a Service
Published by Laura czajkowski July 11, 2012 in General
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.
If you’re interested, sign up for the 15,00 UTC talk or the later one at 18.00 UTC.
Are you a technical writer -Want to work with amazing people and great team- Come join us
Published by Laura czajkowski July 6, 2012 in We're hiring!
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.
Apply online, if you have any questions drop by #launchpad
We’re hiring software engineers to work on cloud projects in Canonical
Published by Laura czajkowski in We're hiring!
Location: Flexible. If home based, reliable broadband connectivity required.
Role Summary
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!
Meet Martin Packman in the Blue squad
Published by Laura czajkowski July 5, 2012 in Meet the devs
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.
Meet Vincent Ladeuil who works in the Blue Squad on Launchpad
Published by Laura czajkowski July 3, 2012 in Meet the devs
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: Can we see something that you’ve worked on?
Vincent: https://launchpad.net/bzr and http://babune.ladeuil.net:24842/
Laura: Where do you work?
Vincent: At home
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: Tell us something really cool about Launchpad that not enough people know about.
Vincent: Pass 🙂
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)).
