0

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.

advanced search for private information types

Privacy terminology is restored

We reverted the information type terminology changes introduced a few months ago.

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.

change information type


5

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.

hide your comment

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.

your hidden 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.

 


1

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:

A notification of a failed copy to a PPA.

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.


5

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.

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.

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.


2

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.

 


0

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.


0

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

  Required skills and experience

Desirable skills and experience

Apply online, if you have any questions drop by #launchpad


0

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

Required Skills and Experience

Desired Skills and Experience

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


2

Meet Martin Packman in the Blue squad

Published by Laura czajkowski July 5, 2012 in Meet the devs

Martin Packman

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.


1

Meet Vincent Ladeuil who works in the Blue Squad on Launchpad

Published by Laura czajkowski July 3, 2012 in Meet the devs

Vincent

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? View from where I sit
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)).


Previous Entries
Next Entries