Author Archive

How Novacut uses Launchpad

Tuesday, November 20th, 2012

Launchpad has been a key tool used in developing Novacut. I use Launchpad for code hosting, bug tracking, daily builds, and more. For almost two years I’ve been doing monthly stable releases on Launchpad, and Novacut now spans six separate Launchpad projects. To say the least, I’ve learned a lot about Launchpad in the process.

I don’t think Novacut could be where it is today without Launchpad, so I want to pass on some of what I’ve learned the past two years. Here are my five essential Launchpad best practices:

1. Daily Builds

I’m always very thankful that early on Paul Hummer took the time to school me on using Source Package Recipes to do daily builds. This Launchpad service gives you automated package builds across multiple architectures, and multiple Ubuntu releases.

I don’t know how to emphasize this enough, but seriously, you need daily builds. As a point of reference, daily builds are the 3rd item in the famed Joel Test.

These builds are triggered simply by making commits to the appropriate bzr branch on Launchpad (usually your trunk branch). You’ll automatically get up to one build per 24-hour period, and you can manually trigger additional builds when needed.

You can include your debian/ packaging directory in your project source tree, or you can keep debian/ in a separate bzr branch. For the Novacut components, I’ve found it most helpful to keep debian/ in the source trees because it’s handy to be able to land a code change and its corresponding packaging change in a single merge. This works for us because we currently can use the exact same debian/ for all the Ubuntu versions we support. If that’s not true for your project, you’ll need multiple debian/ branches.

For reference, here’s the Novacut Source Package Recipe.

2. Unit Tests

You should run your unit tests during your package builds, and you should fail the build when any unit test fails. This is particularly important for daily builds, because this will prevent a package with broken unit tests from reaching your daily PPA.

The Launchpad build servers are strict and unforgiving environments, which is a good thing when it comes to unit tests. The build servers are also probably quite different from your local development environment. On countless occasions our daily builds have caught failures that only occur on i386 (my workstation is amd64), or only occur on an Ubuntu release other than the one I’m running, etc.

To run your unit tests during the package build, you’ll need to modify your debian/rules file as appropriate. If you’re using debhelper, add an override_dh_auto_test target.

You might also need to add additional packages to the Build-Depends section of your debian/control file, packages that are needed by the unit tests but are otherwise not needed by the build itself.

For reference, here’s the debian/rules file used to run the Dmedia unit tests (which is also a handy Python3 example).

3. Track Ubuntu+1

When a new Ubuntu version opens up for development, I immediately start doing daily builds on the development version, even though I don’t typically upgrade my own computers till around 4 months into the cycle.

I use daily builds on the development release as an early warning system. With no extra effort on my part, these builds give me a heads-up about code or packaging changes that might be needed to make Novacut work well on the next Ubuntu release.

To enable daily builds on the next Ubuntu version, just go to your Source Package Recipe, click on “Distribution series”, and check the box for the newest series. Now you’ll have daily builds on the newest Ubuntu version, in addition to all the versions you were already building for.

For example, I’m currently in the process of enabling daily builds for Raring, as you can see in the Microfiber Source Package Recipe. And I did indeed encounter a build failure on Raring, seemingly caused by a debhelper issue.

For the first month or so in a cycle, I don’t tend to worry much about build failures on the development version. But after the dust has settled a bit, I make sure to keep the builds in working order, and I even do monthly stable releases for the Ubuntu development version. Again, I do all this pro-actively even before I personally start running the newest Ubuntu version.

4. PPAs & Users

Whenever someone asks me why I use Launchpad instead of github, my short answer is always, “PPAs and users”.

Source Package Recipes give you much more than just a build, they give you daily packages that are easily consumable by your testing community and early adopters. This tight feedback loop prevents you from running too far ahead without getting a good reality check from your target users.

Keep in mind that for some products, the early adopters willing to install from a PPA might not be all that representative of your target user. So when it comes to making design decisions, you might need to politely ignore certain feedback from some of these early adopters. In my experience, this wont cause any hard feelings as long as you have clearly communicated who your target user is, and why.

For reference, you might look at the way we’ve defined the Novacut target user.

I recommend creating PPA names that are well-branded and easy to remember. First, create a Launchpad team with the same name as your product. In our case, we have a ~novacut team. Second, I recommend creating a daily and a stable PPA owned by the same team. In our case, that gives us two easy to remember PPAs:

Although none of our target users (professional video editors) currently use Ubuntu to do their job, I’ve been surprised by how many follow Novacut’s development via our stable PPA, and even our daily PPA. This has helped keep us on track, and has helped us build customer loyalty even before we have a finished product.

For me personally, this daily user engagement also makes the design and development process more enjoyable. It’s hard to empathize with an abstract persona; it’s easier to solve specific problems for specific people.

5. Use Apport

Till recently I didn’t realize that you can use Apport for automated crash reporting in unofficial packages delivered through a PPA.

We haven’t had Apport integration for that long, but it’s already provided us with dozens of highly valuable crash reports. Almost immediately some hardware specific issues came to light and were fixed, convincing me that a key benefit of Apport is knowing how your app might misbehave on a larger, more variable pool of hardware.

Apport also helped some rare bugs come to light. I thought Dmedia was basically crash-free, but those one-in-a-thousand bugs pop out quickly when thousands of people are running it. Most of these bugs would have eventually been found by one of our core devs, but the quicker a bug is discovered, the quicker and easier the bug is to fix.

For more info, check out this blog post and this screencast, where I covered our Apport integration in detail.

And for reference, see the merge proposal that added Apport integration in Novacut.

A big thank you to Jason DeRose for sharing how his project uses Launchpad on a daily basis.

 

Launchpad Workshop at UDS-R

Tuesday, October 23rd, 2012

After the success of the Launchpad clinics at the last UDS-Q we’ve decided to run some more! This time removed the sterile name of clinic and called them workshops.

If you want to get involved, scratch that itch, learn how to fix that irksome bug that has been bugging you’re not alone. Everyone probably has at least one that they’d like to see fixed.  The problem is now knowing how to fix them or maybe they don’t know how to set up the Launchpad development  environment, well lucky for you we have a lot of Launchpad developers at UDS-R and we’d like to help you help get bugs fixed!

The idea being if you have a bug you would like to fix, or pointed in the right direction  that we’ll be there to help you get on the road  to offer advice on every step of the Launchpad development process from Lines of code, to branch reviews to getting things done. We’ll have EC2 instances ready for you to develop on, so if you haven’t already gone through the process of setting up local Launchpad development on your machine, you don’t need to worry.

I have created a wiki page on which you should register if you’re going to be attending either of the clinics. Just list your name and the ID of the bug(s) you want to work on on that page. We’ll check the bugs out and get in touch with you if we think they’re too big to work on in the clinics – in which case we’ll try and work with you to get them fixed over a longer period. We’ve added the event to summit schedule, for Tuesday and Thursday of UDS so why not sign up and come along!

If you’ve never contributed before, Graham Binns has written a useful guide to contributing to  Launchpad.  He has also done up a screencast on fixing a bug in Launchpad.

Parallel testing is live

Monday, September 24th, 2012

One of the projects the Launchpad Squads (yellow) have been working on has been the Parallel Testing during the last cycle, this has now been completed and is now in operation. WebOps have today finished setting up parallel testing in buildbot. Buildbot-poll has been updated to know about the new builders, and the developers have  confirmed that [testfix] and automatic stable merging etc. work fine. Nothing should have changed except that builds now take 35 minutes rather than 6.5 hours.

If something goes wrong, http://lpbuildbot.canonical.com/waterfall and https://dev.launchpad.net/yellow/ParallelTestingTroubleshooting may be helpful. The buildbot master is still praseodymium, but the slaves are new: sluagh for devel, and radande for db-devel. If you need packages upgraded on the slaves, poke WebOps as before.

If you would like to follow the discussion on this topic you’ll find more on the Launchpad development mailing list

Launchpad Builders update

Sunday, September 16th, 2012

We have recovered some of the affected builders, more will be coming back on later this week with the remainder to come in a few weeks when we have new hardware.  Until then launchpad builders will be at a reduced build capacity. l

We apologise for the inconvenience and we’re sorry for the disruption to your service.

Reduced Builder Capacity

Thursday, September 13th, 2012

The Launchpad builders are currently operating at reduced build capacity. We are aware of the issue and have raised this with IS who are investigating the situation.  If you are having any issues with your builds please ask for help in #launchpad.

We apologise for the inconvenience and we’re sorry for the disruption to your service.

Disruption to PPA uploading and building

Wednesday, August 15th, 2012

Launchpad services will be affected by scheduled maintenance from 22:00 UTC Friday 17th August until 02:00 UTC Saturday 18th August.

During this time, you’ll be unable to upload or build PPA packages. However, packages will remain available for download from PPAs just like normal.

Maintenance starts: 22:00UTC Friday 17th August
Expected back: 02:00 UTC Saturday 18th August

Thanks for your patience while we maintain the hardware powering these services.

Launchpad downtime August 16th

Wednesday, August 15th, 2012

Launchpad PPA build services will be affected by an emergency maintenance between 07.00UTC and 19.00 UTC on Thursday 16th  August.

During this time there will be significantly reduced capacity in the PPA build farm.

Official Ubuntu distribution builders will be largely unaffected by this maintenance.

Interruption starts: 07.00 UTC 16th August 2012
Expected back: 19.00 UTC 16th August 2012

Thanks for your patience while we maintain the hardware powering these services.

Webinar on Ubuntu MAAS: Metal as a Service

Wednesday, July 11th, 2012

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

Friday, July 6th, 2012

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

Friday, July 6th, 2012

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!