Canonical Voices

Posts tagged with 'motu'

Daniel Holbach

A lot of really great things are coming together right now: tomorrow we kick off Ubuntu Global Jam for the 12.04 cycle, additionally we will have Fix-It Friday tomorrow!

The Ubuntu developer community is putting a lot of effort into this event. There will be experienced developers who

  • take the time to answer all the questions you have,
  • help you fix problems,
  • review code for you,
  • use the time to clear up the sponsoring queue.

Here’s something you can do for us: get involved! Seriously, the more people show up, the more fun it will be, so if you are still hesitant, just show up: We are friendly, we’ll help out and we will have a great time.

If you want to prepare yourself a bit, check out these articles first: Introduction to Ubuntu development, Getting Set Up and Fixing a bug in Ubuntu. Please also give us feedback about them. If there’s anything unclear, wrong or confusing, we will fix it. We not only want a precise 12.04 release, but also precise Ubuntu development docs!

I’m looking forward to seeing you all tomorrow! :)

Read more
Daniel Holbach

Since I heard it, I always like the idiom “to hit the ground running”. There’s no really good German translation of it, but the thought of arriving somewhere, knowing what to do and how to do it definitely has its charm. In practical terms it’s often hard, especially if there’s complicated rules, tools and processes.

I won’t deny that there’s an interesting learning experience involved if you want to get into Ubuntu development. The experience will involve a couple of round-trips, as there is no one-size-fits-all solution to every single package or piece of software.

The good news is though[1]: it’s a lot easier than you think and we’re there to help you.

On Friday, 2nd March 2012, a lot of Ubuntu developers and contributors are going to be there to actively help you get started with Ubuntu Development. This is a great opportunity to ask all your questions, get to know a bunch of really friendly and helpful people and learn lots and lots about Ubuntu and Open Source development. It will almost be like hitting the ground running.

So you like the idea to help make Ubuntu better for millions of users on servers, desktops, laptops, TVs, phones and elsewhere?

There are two lists of items we want to look into fixing together:

  1. Packages which don’t build anymore.
    If you have worked with compiling source code before, you know that a mistake like a syntax error can get you into a situation where the build is broken and does not succeed. There are lots of other reasons why this might happen, a good idea is usually to review the build log referenced in the link above.
  2. Bugs which have been fixed elsewhere.
    Our bug life cycle works like this: make sure the bug can be reproduced reliably, gather all the information necessary, figure out if it’s an Ubuntu-specific problem or if it happens in the vanilla code of the software authors as well, then forward the bug with all the relevant information upstream. The Launchpad bug tracker is a great tool, which puts us into the situation where we are able to go through bugs which were fixed elsewhere already. Taking these fixes and applying them to Ubuntu is a great target for improvements, especially being eight weeks away from release.

There’s only two things you need to do:

  1. Make yourself familiar with Ubuntu development. Just these three articles will give you a good start: Introduction to Ubuntu development, Getting Set Up and Fixing a bug in Ubuntu. (Feel free to read more if you like. ;-) )
  2. Join us in #ubuntu-motu on irc.freenode.net on Friday, 2nd March 2012 and we will answer all your questions, hang out with you, review code for you and have a good time.

The great thing is: this also coincides with Ubuntu Global Jam, so expect people from all around the globe to hang out and make Ubuntu better.

[1] … and this is where the actual blog post starts. :-)

Read more
Daniel Holbach

WOW. So this was our first Fix-It Friday and there’s still a few to come until release. Here’s what we collectively got through:

What the people above can do, you can do easily! Just make sure you’re there next time. I’m super super happy about Fix-It Friday turned out the first time and as I said above: there will be more… and this one isn’t even over yet! :-)

Thanks everyone and ROCK ON!

Read more
Daniel Holbach

Every Friday
Every Friday…
we hack with you

...we hack together with you...

on Ubuntu

...on Ubuntu.

It's no Rocket Science

It's no Rocket Science...

but rather a lot of fun

...but rather a lot of fun!

Join us

Join us and...

...you'll make lots of friends!

...you'll make lots of friends!

Here’s what you need to do:

  1. Read the first few articles.
  2. Join us in #ubuntu-motu on irc.freenode.net on Friday.
  3. Have fun and start making Ubuntu better!

More info here.

Read more
Daniel Holbach

I have been writing weekly Ubuntu development updates for about one cycle now. As many seem to like these updates, it’s time to raise the bar a bit. As I can’t do this just on my own, I need your help.

After some discussion with the Ubuntu News team, we agreed that development news can now be submitted to the ubuntu-news-team mailing list by simply sending a mail there with “[dev]” in the subject. To get a better idea of which kind of news we are looking for, check out the development news wiki page.

This is a very important service, as it will help us all to stay informed in our huge development community, it will make our efforts more transparent and inspire others to help out or get involved in similar efforts, so if you have just a few news bits, send them there. If you want to thank somebody for their work, tell us about it.

Also if you have ideas for additional topics we should write about, either send a mail or add a comment below.

Also am I looking for contributors, who would like to get involved in writing and collecting information about Ubuntu development. It’s not a huge amount of work, but should be pretty fun. If you are interested, please leave a comment below or drop me an email.

Read more
Daniel Holbach

Some weeks ago, I asked for feedback in a survey about Ubuntu development. Particularly, how well we reach out and how Ubuntu development is generally perceived were focus points of the survey. The great thing is: we had ~350 people replying and we have lots of great feedback and ideas in the results.

You can download the summary (including all the answers) here.

Let’s use all the feedback to make Ubuntu development even easier.

Thanks everyone for your replies!

Read more
Daniel Holbach

I love planning a new Ubuntu release. It’s a great experience to take a few steps back and look at the biggest challenges and opportunities in your area of interest and try to identify the most promising.

Personally, I want us to get better at involving interested Ubuntu users in the development process. We have gotten better and better over the years, but there’s still things we can do better. The fantastic answers in the survey I announced recently helped a lot to see the issues more clearly. (Expect a report of the survey soon.)

So here’s the list of blueprints I registered and where I expect some movement next cycle (feel free to subscribe to any of these, and follow along, if you’re not at UDS):

  • Celebrating developer contributions
    How can we get better at celebrating contributions to Ubuntu development? There is massive amounts of great work going into Ubuntu, some of this is under the radar because it is less visible. Celebrating this more publicly would be both inspiring for those who did the good work, and others who didn’t know about the great work before.
  • Developer Advisory Team
    As opposed to having fully-fledged 1-on-1 mentoring, we might want to think of a much more light-weight approach and coordinate efforts such as: 1) reach out to new contributors, thank them for their work and get feedback, 2) reach out to people who might be ready to apply for upload rights and help them, 3) reach out to contributors that went inactive and get feedback from them and offer help.This should be easily manageable by a small team and would make the developer world a much more social experience.
  • Development documentation improvements
    It’d be worth to discuss the list of open issues of our developer documentation and review the results of the recent survey.
  • Making Harvest rock
    Harvest hasn’t seen much development recently, but we still need a good place to summarise all the needed work in the distribution.Problems both in representation and data should be discussed.
  • Reaching out to future Ubuntu developers
    There is a huge interest in getting involved in Ubuntu development. We want to better reach out to everybody who is interested. The recent survey data will probably help with the discussion of this.
  • Weekly Ubuntu Development News
    We have weekly development updates already, so these can serve as a good piece of news infrastructure. We need to put the project on broader feet and figure out submissions processes, etc. Also are we going to talk about new interesting news bits we might want to include.

These are just the sessions that I will be leading, there will be loads more I’ll attend and contribute to though. :-)

I’m looking forward to this great UDS!

Read more
Daniel Holbach

The Ubuntu Packaging Guide has made a lot of progress since its inception and we have a bunch of great articles together already, which make it a lot easier for newcomers to get a sense of direction and find out how to use the tools.

Some of us have been filing bug reports about it recently, and it’d be great to get them fixed and out there. If you are new to the packaging world, but still want to help out, just say so in your merge proposal and we give it another fact check.

The good news is, the process of fixing these bugs is quite simple, just:

  • bzr branch lp:ubuntu-packaging-guide
  • <edit and fix>
  • bzr commit
  • bzr push lp:~<yourlaunchpadid>/ubuntu-packaging-guide/<bugnumber>
  • bzr lp-open
  • <click on “(+) Propose for merging”>

Here is a list of bugs that would be great to have fixed:

And here is a list of articles that still need to be written:

Be bold, propose changes – every little fix will help.

(Here’s a list of more bugs.)

If you haven’t checked out the Packaging Guide yet, here is it online, or install it like this:

  1. sudo add-apt-repository ppa:ubuntu-packaging-guide-team/ppa
  2. sudo apt-get update
  3. sudo apt-get install ubuntu-packaging-guide

Read more
Daniel Holbach

You were always interested in Ubuntu Development and gave it a try already? Perfect!

With Ubuntu 11.10 almost out the door, we started the planning of the 12.04 (precise) development cycle and we would love to know how well our documentation is known and working today, so we can see what we can improve.

SurveyPlease give us your feedback in this short survey – it just takes a few minutes (if you’re not trying to write a novel in reply). Have your say and help us improve!

Thanks a bunch in advance! :)

Read more
Daniel Holbach

I have written about our sponsorship process loads of times already. When new contributors have no upload rights to Ubuntu yet, this process ensures that we get the code reviewed and included in Ubuntu. In the cases you branch a source package, make changes, push to Launchpad and propose a merge. The other alternative is to add a patch to a bug report and subscribe the sponsors team.

Over the last few releases we improved documentation, tools and processes and got more people involved.

I’d like to have your comment as a contributor or as a reviewer: how well does it work for you? What are you remaining gripes? What do you love about it?

Read more
Daniel Holbach

Your chance to get involved!

Barry just spilled the beans about it: we are going to have a dh_python2 porting jam on 23rd June. Here’s what he says:


This Thursday, June 23rd, we are going to have a dh_python2 porting jam. If you know about packaging, and have meddled with Python packaging before, we invite you to hang out and port a load of packages with us.

We have some documentation to explain better what exactly we’re going to be doing, and why:

https://wiki.ubuntu.com/BarryWarsaw/PythonHelpers

You are of course welcome to start working on these, fixing them and getting them included in Ubuntu, but if you wait for the 23rd, we will offer this for you:

  • IRC Training sessions in #ubuntu-pyjam at 1300 and 1800 UTC
  • Lots of fun and good atmosphere
  • Reviewers who can check and upload your code for you. (In addition to

our regular patch pilots we will have additional people to make
sure all merge requests are tended to.)

If this sounds great to you, make sure pencil in this Thursday, June 23rd into your calendar and just show up in #ubuntu-pyjam on irc.freenode.net.


Just to make it clear: you will need a bit of packaging experience to get involved, but hanging out in the channel and working your way through these guides (Intro, Get Set Up, Fix bugs) should be a very good start.

Thanks a lot Barry for organising this – this will be awesome! :-)

Read more
Daniel Holbach

Weekly Ubuntu Development Update

Ubuntu Development Update

Development of Oneiric (Ubuntu 11.10) is in full swing, we just got Alpha 1 out last week and here’s the list of dates that are coming up in the next few weeks:

  • June 30th, Debian Import Freeze which means that packages will not be synced automatically any more, but have to be requested manually.
  • July 7th, release of Alpha 2.
  • July 11th to 15th, Ubuntu Developer Week! A week full of development tutorials, workshops and interactive sessions.
  • August 4th, release of Alpha 3.
  • August 11th, Feature Freeze until which features have to have mostly landed in Ubuntu. They will of course still have bugs that have to get ironed out, but most of the hard work will be there already.

As you can see times are exciting right now. There is a lot of hard work going on, lots is still broken in Oneiric, but it’s a great time to get your feet wet, try out things and fix a few bugs on the way.

I’m very happy to see that Full Circle Magazine is now having a new series about Ubuntu Development. Issue 49 has the first installment of this. Be sure to check it out!

New Contributor

This week I talked to Paolo Sammicheli, who is an Ubuntu Member from the Italian Community. He was involved in several things like translations, marketing, advocacy and testing. He also is an UDS addict and since UDS Jaunty spent his holidays attending it. He says “This cycle I decided to move my interests into development and I’m slowly learning packaging. Spare time is never enough :)

I asked Paolo what his personal experience of the development was like and he had this to say:

  • Yes, I tried some merges and few sync. The experience was good, also because I’ve found in the Italian Dev Team people willing to mentoring me and being already an Ubuntu Member helped me to find easily who-ask-what.
  • Paolo was struggling a bit to find tasks to work on. Some of the bitesize bugs he tried were solved already, but when he tried a few merges that worked out better for him, because “comparing the previous ubuntu version with the debian version you start understanding how patches works, how tools works and so on.
  • When merging Paolo found it helpful to get in touch with the person who uploaded it last. A bunch of people were happy to review his merge and upload it. In some cases he didn’t get a reply, which was a bit frustrating. Looks like this is something we can all improve!

Get Involved

  1. Read the Introduction to Ubuntu Development. It’s a short article which will help you understand how Ubuntu is put together, how the infrastructure is used and how we interact with other projects.
  2. Follow the instructions in the Getting Set Up article. A few simple commands, a registration at Launchpad and you should have all the tools you need, and you’re ready to go.
  3. Check out our instructions for how to fix a bug in Ubuntu, they come with small examples that make it easier to visualise what exactly you need to do.

Find something to work on

Pick a bitesize bug. These are the bugs we think should be easy to fix. Here’s a few examples:

In addition to that there are loads more opportunities over at Harvest.

Talk to us in #ubuntu-motu on irc.freenode.net to get all your questions answered.

Read more
Daniel Holbach

Development Documentation

I’m happy to say that the Packaging Guide project has seen a lot of activity recently, so a bunch of articles have been improved and new articles been added. Thanks a lot to Andrew, Barry and others.

You can download it or read it on its preliminary home. (Expect an announcement of its new and lasting place soon.)

I got a number of questions about the guide in the last few days and I think it’d make sense to clarify the intention behind the guide. We never intended to rewrite or replace other fantastic documentation about packaging that exists already (think Debian New Maintainers’ Guide, Debian Policy Manual, etc.), but we want to have a place where new contributors to Ubuntu get a good and well-rounded introduction to Ubuntu, plus a more maintainable place for “knowledge-base type” articles that are currently spread across the wiki and other places in varying forms of style or out-of-date-ness.

For the project we need feedback and help. If you are interested in helping out, please check out the list of open requests, read the current guide and file bugs.

I’m very excited about this project and feel the quality of it is getting better and better.

Read more
Daniel Holbach

Getting people involved

As part of my job I have often thought about what motivates somebody to get involved with Ubuntu development or more generally with Open Source development in general. There’s a couple of conclusions I came through, both through my own experience and observations and discussions with others. Here’s my Top 3:

  1. The project needs to be exciting. The atmosphere needs to be welcoming and friendly.
  2. The documentation needs to be clear.
  3. Contributors need to find their first tasks easily.

Regarding 1) I think we’re doing a great job. It’s a lot of fun to be part of the Ubuntu development team and I think almost everybody can easily say that they made lots of friends there. Working on Ubuntu is exciting, because you fix problems not only for you, but also for millions of users.

We’re actively working on 2). The newly revamped Packaging Guide is still work in progress, but expect an announcement soon.

One area of focus for this cycle should be 3). We often face new contributors who say “Yeah, I read all the documentation – what do I do now?” There’s all kinds of tasks we can set for new contributors. We can try to just point them to Harvest, we can involve them in some organised activities, and lots of other things.

In the UDS session “Initiatives to involve new developers” we discussed a very light-weight approach: if you encounter a bug that should be easy to solve, but probably not what you want to work on yourself right now, just

  • tag it as ‘bitesize’,
  • subscribe yourself,
  • add a comment saying that it should be a bug that’s simple to fix and
  • offer your help.

It’s not a huge commitment to help somebody fix one bug, so let’s all try to tag a few more to make sure we give new contributors something to sink their teeth in.

Luckily: there’s a script in oneiric’s ubuntu-dev-tools, that does just that: it’s called “bitesize”. :-)

Read more
Daniel Holbach

I just set up a daily build for the Ubuntu Packaging Guide. To get the latest goodness, simply:

  1. sudo add-apt-repository ppa:ubuntu-packaging-guide-team/ppa
  2. sudo apt-get update
  3. sudo apt-get install ubuntu-packaging-guide
  4. <point your browser to /usr/share/doc/ubuntu-packaging-guide>

Once installed, you get a handy packaging guide in PDF, HTML, Single HTML and ePub formats.

If you have any feedback from the guides, please file bug reports. Also can we need some help massaging the old packaging guide into reStructuredText. Have a look at the open bug reports to see what we’re currently working on and looking for.

Read more
Daniel Holbach

This is another article of the new Ubuntu Packaging Guide project. Please leave your comments below, or report a bug on it, or start helping out. Just branch the code and get involved.

The article below is all about fixing bugs in Ubuntu.


Fixing a bug in Ubuntu

Introduction

If you followed the instructions to get set up with Ubuntu Development, you should be all set and ready to go.

As you can see in the image above, there is no surprises in the process of fixing bugs in Ubuntu: you found a problem, you get the code, work on the fix, test it, push your changes to Launchpad and ask for it to be reviewed and merged. In this guide we will go through all the necessary steps one by one.

Finding the problem

There is a lot of different ways to find things to work on. It might be a bug report you are encountering yourself (which gives you a good opportunity to test the fix), or a problem you noted elsewhere, maybe in a bug report.

Harvest is where we keep track of various TODO lists regarding Ubuntu development. It lists bugs that were fixed upstream or in Debian already, lists small bugs (we call them ‘bitesize’), and so on. Check it out and find your first bug to work on.

Figuring out what to fix

If you don’t know the source package containing the code that has the problem, but you do know the path to the affected program on your system, you can discover the source package that you’ll need to work on.

Let’s say you’ve found a bug in Tomboy, a note taking desktop application. The Tomboy application can be started by running /usr/bin/tomboy on the command line. To find the binary package containing this application, use this command:

$ apt-file find /usr/bin/tomboy

This would print out:

tomboy: /usr/bin/tomboy

Note that the part preceding the colon is the binary package name. It’s often the case that the source package and binary package will have different names. This is most common when a single source package is used to build multiple different binary packages. To find the source package for a particular binary package, type:

$ apt-cache show tomboy | grep ^Source:

In this case, nothing is printed, meaning that tomboy is also the name of the binary package. An example where the source and binary package names differ is python-vigra. While that is the binary package name, the source package is actually libvigraimpex and can be found with this command (and its output):

$ apt-cache show python-vigra | grep ^Source:
Source: libvigraimpex

Getting the code

Once you know the source package to work on, you will want to get a copy of the code on your system, so that you can debug it. This is done by branching the source package branch corresponding to the source package. Launchpad maintains source package branches for all the packages in Ubuntu.

Once you’ve got a local branch of the source package, you can investigate the bug, create a fix, and upload your proposed fix to Launchpad, in the form of a Bazaar branch. When you are happy with your fix, you can submit a merge proposal, which asks other Ubuntu developers to review and approve your change. If they agree with your changes, an Ubuntu developer will upload the new version of the package to Ubuntu so that everyone gets the benefit or your excellent fix – and you get a little bit of credit. You’re now on your way to becoming an Ubuntu developer!

We’ll describe specifics on how to branch the code, push your fix, and request a review in the following sections.

Work on a fix

There are entire books written about finding bugs, fixing them, testing them, etc. If you are completely new to programming, try to fix easy bugs such as obvious typos first. Try to keep changes as minimal as possible and document your change and assumptions clearly.

Before working on a fix yourself, make sure to investigate if nobody else has fixed it already or is currently working on a fix. Good sources to check are:

  • Upstream (and Debian) bug tracker (open and closed bugs),
  • Upstream revision history (or newer release) might have fixed the problem,
  • bugs or package uploads of Debian or other distributions.

If you find a patch to fix the problem, say, attached to a bug report, running this command in the source directory should apply the patch:

$ patch -p1 < ../bugfix.patch

Refer to the patch(1) manpage for options and arguments such as --dry-run, -p<num>, etc.

Testing the fix

To build a test package with your changes, run these commands:

$ bzr bd -- -S -us -uc
$ pbuilder-dist <release> build ../<package>_<version>.dsc

This will create a source package from the branch contents (-us -uc will just omit the step to sign the source package) and pbuilder-dist will build the package from source for whatever release you choose.

Once the build succeeded, install the package from ~/pbuilder/<release>_result/ (using sudo dpkg -i <package>_<version>.deb). Then test to see if the bug is fixed.

Documenting the fix

It is very important to document your change sufficiently so developers who look at the code in the future won’t have to guess what your reasoning was and what your assumptions were. Every Debian and Ubuntu package source includes debian/changelog, where changes of each uploaded package are tracked.

The easiest way to do this is to run:

$ dch -i

This will add a boilerplate changelog entry for you and launch an editor where you can fill out the blanks. An example of this could be:

specialpackage (1.2-3ubuntu4) natty; urgency=low

  * debian/control: updated description to include frobnicator (LP: #123456)

 -- Emma Adams <emma.adams@isp.com>  Sat, 17 Jul 2010 02:53:39 +0200

dch should fill out the first and last line of such a changelog entry for you already. Line 1 consists of the source package name, the version number, which Ubuntu release it is uploaded to, the urgency (which almost always is ‘low’). The last line always contains the name, email address and timestamp (in RFC 5322 format) of the change.

With that out of the way, let’s focus on the actual changelog entry itself: it is very important to document:

  1. where the change was done
  2. what was changed
  3. where the discussion of the change happened

In our (very sparse) example the last point is covered by (LP: #123456) which refers to Launchpad bug 123456. Bug reports or mailing list threads or specifications are usually good information to provide as a rationale for a change. As a bonus, if you use the LP: #<number> notation for Launchpad bugs, the bug will be automatically closed when the package is uploaded to Ubuntu.

Committing the fix

With the changelog entry written and saved, you can just run:

debcommit

and the change will be committed (locally) with your changelog entry as a commit message.

To push it to Launchpad, as the remote branch name, you need to stick to the following nomenclature:

lp:~<yourlpid>/ubuntu/<release>/<package>/<branchname>

This could for example be:

lp:~emmaadams/ubuntu/natty/specialpackage/fix-for-123456

So if you just run:

bzr push lp:~emmaadams/ubuntu/natty/specialpackage/fix-for-123456
bzr lp-open

you should be all set. The push command should push it to Launchpad and the second command will open the Launchpad page of the remote branch in your browser. There find the “(+) Propose for merging” link, click it to get the change reviewed by somebody and included in Ubuntu.

Read more
Daniel Holbach

This is the second article showcasing what we have in the new packaging guide already. The article this time is about getting your development environment set up.


Getting Set Up

There are a number of things you need to do in the beginning to enable you to do Ubuntu development. A few of them you have to do locally on your system. In addition to that you also need to inform Launchpad about yourself, so it accepts changes you want to make.

When you followed all the steps in this article,

  • you have all the tools to do Ubuntu development installed on your machine,
  • your local developer tools know about you, which simplifies work a lot,
  • you can do local builds of packages,
  • you can interact with other developers and propose your changes on Launchpad to get merged,
  • you can upload packages to Launchpad, so they are hosted in your Personal Package Archive (PPA).

Run the development version

It is advisable to run the current development version of Ubuntu. It will allow you to test changes in a “live environment” where they are actually built and tested in the development release you upload them to.

https://wiki.ubuntu.com/UsingDevelopmentReleases shows a variety of ways to use the development release in a safe way.

Install the tools locally

There are a number of tools that will make your life as an Ubuntu developer much easier. You’ll encounter these tools later in this guide. To install most of the tools you’ll need, run this command:

$ sudo apt-get install gnupg pbuilder \
  ubuntu-dev-tools bzr-builddeb apt-file

These packages include:

  • gnupgGNU Privacy Guard contains tools you will need to create a cryptographic key with which you will sign files you want to upload to Launchpad.
  • pbuilder – a tool to do a reproducible builds of a package in a clean and isolated environment.
  • ubuntu-dev-tools (and devscripts, a direct dependency) – a collection of tools that make many packaging tasks easier.
  • bzr-builddeb (and bzr, a dependency) – distributed version control tools that makes it easy for many developers to collaborate and work on the same code while keeping it trivial to merge each others work.
  • apt-file provides an easy way to find the binary package that contains a given file.
  • apt-cache provides even more information about packages on Ubuntu.

Setting up a GPG key

GPG stands for GNU Privacy Guard and it implements the OpenPGP standard which allows you to sign and encrypt messages and files. This is useful for a number of purposes. In our case it is important that you can sign files with your key, so they can be identified as something that you worked on. If you upload a source package to Launchpad, it will only accept the package if it can absolutely determine who uploaded the package.

To generate a new GPG key, run:

$ gpg --gen-key

GPG will first ask you which kind of key you want to generate. Choosing the default (RSA and DSA) is fine. Next it will ask you about the keysize. The default (currently 2048) is fine, but 4096 is more secure. Afterward, it will ask you if you want it to expire the key at some stage. It is safe to say “0”, which means the key will never expire. The last questions will be about your name and email address. Just pick the ones you are going to use for Ubuntu development here, you can add additional email addresses later on. Adding a comment is not necessary. Then you will have to set a passphrase. Choose a safe one. Now GPG will create a key for you, which can take a little bit of time; it needs random bytes, so if you give the system some work to do it will be just fine. Move the cursor around!

Once this is done, you will get a message similar to this one:

pub   4096R/43CDE61D 2010-12-06
      Key fingerprint = 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
uid                  Daniel Holbach <dh@mailempfang.de>
sub   4096R/51FBE68C 2010-12-06

In this case 43CDE61D is the key ID.

To upload (the public part of) of your key to a keyserver, so the world can identify messages and files as yours, just run:

$ gpg --send-keys <KEY ID>

There is a network of keyservers that will automatically sync the key between themselves.

Setting up an SSH key

SSH is a network protocol that allows you to exchange data in a secure way over the network. In a lot of cases you will use it to access and open a shell on another machine. It is also very useful to transfer files in a secure way.

To generate a SSH key, run:

$ ssh-keygen -t rsa

The default file name usually makes sense, so you can just leave it as it is. For security purposes, it’s highly recommended that you use a passphrase.

We will use the SSH key to securely push code changes to Launchpad.

Setting up pbuilder

pbuilder allows you to build packages locally on your machine. It serves a couple of purposes:

  • the build will be done in a minimal and clean environment, where you can see if it succeeds in a reproducible way (with no modifications of the local system
  • there is no need to install all necessary build dependencies locally
  • you can set up multiple instances for various Ubuntu and Debian releases

Setting pbuilder up is very easy. Edit ~/.pbuilderrc and add the following line to it:

COMPONENTS="main universe multiverse restricted"

This will ensure that build dependencies are satisfied using all components.

Then run:

$ pbuilder-dist <release> create

where <release> is for example natty, maverick, lucid or in the case of Debian maybe sid. This will take a while as it will download all the necessary packages for a “minimal installation”. These will be cached though.

Set up your development environment

There are a few things you’ll need to set up in your development environment before you can start working on packages.

Launchpad

Launchpad is the central piece of infrastructure we use in Ubuntu. It stores not only our packages and our code, but also things like translations, bug reports, information about the people who work on Ubuntu and which teams they are part of. You’ll also use Launchpad to publish your proposed fixes, and get other Ubuntu developers to review and sponsor them.

You will need to register with Launchpad and provide a minimal amount of information, so that you can download and upload code, submit bug reports, and more.

Setting up an account

If you don’t already have a Launchpad account, you can easily create one. If you have a Launchpad account but cannot remember your Launchpad id, you can find this out by going to https://launchpad.net/people/+me and looking for the part after the ~ in the URL.

Launchpad’s registration process will ask you to choose a display name. It’s encouraged for you to use your real name here. so that your Ubuntu developer colleagues will be able to get to know you better.

When you register a new account, Launchpad will send you an email with a link you need to open in your browser, in order to verify your email address. If you don’t receive it, check in your spam folder.

https://help.launchpad.net/YourAccount/NewAccount has more information about the process and additional settings you can change.

Uploading the GPG key to Launchpad

To find about your GPG fingerprint, run:

$ gpg --fingerprint <email@address.com>

and it will print out something like:

pub   4096R/43CDE61D 2010-12-06
      Key fingerprint = 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
uid                  Daniel Holbach <dh@mailempfang.de>
sub   4096R/51FBE68C 2010-12-06

Head to https://launchpad.net/people/+me/+editpgpkeys and copy the part about your “Key fingerprint” into the text box. In the case above this would be 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D. Now click on “Import Key”.

Launchpad will use the fingerprint to check the Ubuntu key server for your key and, if successful, send you an encrypted email asking you to confirm the key import. Check your email account and read the email that Launchpad sent you. If your email client supports OpenPGP encryption, it will prompt you for the password you chose for the key when GPG generated it. Enter the password, then click the link to confirm that the key is yours.

Launchpad encrypts the email, using your public key, so that it can be sure that the key is yours. If your email software does not support OpenPGP encryption, copy the encrypted email’s contents, type gpg in your terminal, then paste the email contents into your terminal window.

Back on the Launchpad website, use the Confirm button and Launchpad will complete the import of your OpenPGP key.

Find more information at https://help.launchpad.net/YourAccount/ImportingYourPGPKey

Uploading your SSH key

Open https://launchpad.net/people/+me/+editsshkeys in a web browser, also open ~/.ssh/id_rsa.pub in a text editor. It is the public part of your SSH key, so it is safe to share it with Launchpad. Copy the contents of the file and paste them into the text box on the web page that says “Add an SSH key”. Now click “Import Public Key”.

More information is available at https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair

Teaching Bazaar about you

Bazaar is the tool we use to store code changes in a logical way, to exchange proposed changes and merge them, even if development is done concurrently.

To tell Bazaar who you are, simply run:

$ bzr whoami "Bob Dobbs <subgenius@example.com>"
$ bzr launchpad-login subgenius

whoami will tell Bazaar which name and email address it should use for your commit messages. With launchpad-login you set your Launchpad ID. This way code that you publish in Launchpad will be associated with you.

Note: If you can not remember the ID, go to https://launchpad.net/people/+me and see where it redirects you. The part after the “~” in the URL is your Launchpad ID.)

Introducing you to the development tools

Similar to Bazaar, the Debian/Ubuntu packaging tools need to learn about you as well. Simply open your ~/.bashrc in a text editor and add something like this to the bottom of it:

$ export DEBFULLNAME="Bob Dobbs"
$ export DEBEMAIL="subgenius@example.com"

Now save the file and either restart your terminal or run:

$ source ~/.bashrc

(If you use a different than the default shell, which is bash, please edit the configuration file for that shell accordingly.)

Read more
Daniel Holbach

To get the new Ubuntu Packaging Guide project some more exposure, I thought I would blog the first few articles, so if you’re interested in helping out or sharing your feedback, that’d be awesome.

The guide below is an introduction to Ubuntu Development.


Ubuntu is made up of thousands of different components, written in many different programming languages. Every component – be it a software library, a tool or a graphical application – is available as a source package. Source packages in most cases consist of two parts: the actual source code and metadata. Metadata includes the dependencies of the package, copyright and licensing information, and instructions on how to build the package. Once this source package is compiled, the build process provides binary packages, which are the .deb files users can install.

Every time a new version of an application is released, or when someone makes a change to the source code that goes into Ubuntu, the source package must be uploaded to the build machines to be compiled. The resulting binary packages then are distributed to the archive and its mirrors in different countries. The URLs in /etc/apt/sources.list point to an archive or mirror. Every day CD images are built for a selection of different Ubuntu flavours. Ubuntu Desktop, Ubuntu Server, Kubuntu and others specify a list of required packages that get on the CD. These CD images are then used for installation tests and provide the feedback for further release planning.

Ubuntu’s development is very much dependent on the current stage of the release cycle. We release a new version of Ubuntu every six months, which is only possible because we have established strict freeze dates. With every freeze date that is reached developers are expected to make fewer, less intrusive changes. Feature Freeze is the first big freeze date after the first half of the cycle has passed. At this stage features must be largely implemented. The rest of the cycle is supposed to be focused on fixing bugs. After that the user interface, then the documentation, the kernel, etc. are frozen, then the beta release is put out which receives a lot of testing. From the beta release onwards, only critical bugs get fixed and a release candidate release is made and if it does not contain any serious problems, it becomes the final release.

Thousands of source packages, billions of lines of code, hundreds of contributors require a lot of communication and planning to maintain high standards of quality. At the beginning of each release cycle we have the Ubuntu Developer Summit where developers and contributors come together to plan the features of the next releases. Every feature is discussed by its stakeholders and a specification is written that contains detailed information about its assumptions, implementation, the necessary changes in other places, how to test it and so on. This is all done in an open and transparent fashion, so even if you can not attend the event in person, you can participate remotely and listen to a streamcast, chat with attendants and subscribe to changes of specifications, so you are always up to date.

Not every single change can be discussed in a meeting though, particularly because Ubuntu relies on changes that are done in other projects. That is why contributors to Ubuntu constantly stay in touch. Most teams or projects use dedicated mailing lists to avoid too much unrelated noise. For more immediate coordination, developers and contributers use Internet Relay Chat (IRC). All discussions are open and public.

Another important tool regarding communication is bug reports. Whenever a defect is found in a package or piece of infrastructure, a bug report is filed in Launchpad. All information is collected in that report and its importance, status and assignee updated when necessary. This makes it an effective tool to stay on top of bugs in a package or project and organise the workload.

Most of the software available through Ubuntu is not written by Ubuntu developers themselves. Most of it is written by developers of other Open Source projects and then integrated into Ubuntu. These projects are called “Upstreams”, because their source code flows into Ubuntu, where we “just” integrate it. The relationship to Upstreams is critically important to Ubuntu. It is not just code that Ubuntu gets from Upstreams, but it is also that Upstreams get users, bug reports and patches from Ubuntu (and other distributions).

The most important Upstream for Ubuntu is Debian. Debian is the distribution that Ubuntu is based on and many of the design decisions regarding the packaging infrastructure are made there. Traditionally, Debian has always had dedicated maintainers for every single package or dedicated maintenance teams. In Ubuntu there are teams that have an interest in a subset of packages too, and naturally every developer has a special area of expertise, but participation (and upload rights) generally is open to everyone who demonstrates ability and willingness.

Getting a change into Ubuntu as a new contributor is not as daunting as it seems and can be a very rewarding experience. It is not only about learning something new and exciting, but also about sharing the solution and solving a problem for millions of users out there.

Open Source Development happens in a distributed world with different goals and different areas of focus. For example there might be the case that a particular Upstream might be interested in working on a new big feature while Ubuntu, because of the tight release schedule, might be interested in shipping a solid version with just an additional bug fix. That is why we make use of “Distributed Development”, where code is being worked on in various branches that are merged with each other after code reviews and sufficient discussion.

In the example mentioned above it would make sense to ship Ubuntu with the existing version of the project, add the bugfix, get it into Upstream for their next release and ship that (if suitable) in the next Ubuntu release. It would be the best possible compromise and a situation where everybody wins.

To fix a bug in Ubuntu, you would first get the source code for the package, then work on the fix, document it so it is easy to understand for other developers and users, then build the package to test it. After you have tested it, you can easily propose the change to be included in the current Ubuntu development release. A developer with upload rights will review it for you and then get it integrated into Ubuntu.

When trying to find a solution it is usually a good idea to check with Upstream and see if the problem (or a possible solution) is known already and, if not, do your best to make the solution a concerted effort.

Additional steps might involve getting the change backported to an older, still supported version of Ubuntu and forwarding it to Upstream.

The most important requirements for success in Ubuntu development are: having a knack for “making things work again,” not being afraid to read documentation and ask questions, being a team player and enjoying some detective work.

Good places to ask your questions are ubuntu-motu-mentors@lists.ubuntu.com and #ubuntu-motu on irc.freenode.net. You will easily find a lot of new friends and people with the same passion that you have: making the world a better place by making better Open Source software.

Read more
Daniel Holbach

Clearing up the backlog

Things are looking good in the sponsoring queue.

First of all, here’s a quick explanation what the chart is about: to get changes integrated into Ubuntu if you don’t have upload access yet is quite simple: produce the change and get it reviewed by somebody who can upload already. After you’ve successfully worked with the reviewers for a while you can apply for upload rights yourself.

In the past we had times where we struggled a bit keeping up with the backlog of reviews. The way these reviews worked was that they all ended up in a queue and whoever of the developers had a bit of time spent some time working with the submitter to get the change included. The advantages of this approach are clear: the queue made it easy to identify what needs reviewing and contributors worked with more than one developer and learned from them in a very natural way.

To speed up the turnaround time we introduced the concept of patch pilots (it had been very successfully used by the Bazaar team before): somebody would spend a longer period of time not only reviewing the change and giving feedback, but doing their best to get the change ready for inclusion (forwarding it upstream, improving the fix, etc.) and identifying themselves as patch pilot in the main development channel, so whoever had a question about their submission could easily get in touch with somebody who did the review.

I’m very happy to say that this has been working out great. We are much better at giving feedback in a timely manner. This is also due to the fact that Canonical engineers who work on the Ubuntu platform are supposed to do at least a 4 hour shift of patch piloting once a month. Luckily many others like the idea as well, so it was not only a Canonical initiative.

So in addition to reviewers who worked on the queue in an ad-hoc fashion we have a number of people each month who regularly spend a longer period being available for reviews. This is awesome.

If you have a look at the graph above you might think “Oh no, the graph is going up at the end again!” but what’s happening is actually good news:

  • we have loads of submissions coming in each month (more new contributors and contributions)
  • you can see all the small spikes in the graph – that’s submissions being dealt with and new submissions being added
  • also are we cleaning out the big number of bugs with patches attached, they are pre-reviewed and added to the queue if suitable

We all know that it’s frustrating if you don’t get feedback about a change you suggested. I’m happy that we finally have good news for contributors: we care about your work and help you to get it in.

If you want to help out, here’s what you need to do:

Rock on everybody! You are all doing a stunning job!

Read more
Daniel Holbach

Ubuntu Development videocast

I’ll do another videocast later today, 10th March at 16 UTC. Please sign upat ustream.tv, bring all your questions and make it more exciting. All questions around Ubuntu Development are fine, so if there’s something Ubuntu Developer Week you didn’t quite understand or a patch/branch you want us to look at, let’s do it together later on.

 

Read more