Development Update

This will be the last development update of 2011, so let’s see where we stand in terms of 12.04. We are 10 weeks into the release cycle and have still 18 weeks to go. There is definitely still a lot left to be done, but the foundations for a great release have been laid already.

This becomes clearer if you have a look at what the stable+1 team have been doing. Martin Pitt gave a report of the team’s work in December: creating working daily ISOs was a priority. This sounds very obvious, but with lots of moving parts, library transitions and the like, it is great to see how well this was executed. The QA team has done tremendous work on keeping the automatic ISO and upgrade testing working and made a lot of improvements there. A lot of automatic test cases were added to make sure that Ubuntu stays installable even in more complicated setups.  In addition to that was the amount of uninstallable packages down to very very low numbers throughout the month. Go and read the full report if you are interested. It gives you good insights into how many moving parts there are in creating a distribution.

Another great bit of news was that the publisher (the machinery that makes packages available once they are built in Launchpad) can be run every 30 minutes. This shortens the time between upload of a fix and its testing a lot shorter.

Things which need to get done

If you want to get involved in packaging and bug fixing, there’s still a lot of bugs that need to get fixed:

• There’s Merges that need to be done (main, restricted, universe, multiverse).
• Also is the Ubuntu Mozilla team looking for help, so if you’re excited about Mozilla and what’s happening there, join IRC, talk to the guys on #ubuntu-mozillateam on irc.freenode.net.
• And then there’s Security bugs you can take a look at, the team is a friendly bunch and they’re incredibly helpful in getting your patch reviewed.
• There are bitesize bugs.

Also is the Libre Office team looking for Bug Hunting Heroes.

First timers!

Paolo Rotolo got a fix into Debian, Thomas Hood merged resolvconf from Debian and Mark Mims fixed a bug in ganglia. Congratulations to each of you for getting your fix into Ubuntu!

Spotlight: Fixing Ubuntu bugs – how you can be part of every step along the way

The last few issues mentioned the additional focus on QA activities. Quality assurance is tightly integrated in the sum of efforts that make Ubuntu and is quite rewarding if you are part of it. What is better than fixing a bug not only for you, but for millions of users out there?

Not only is it a good thing to do, but also do you get to know a lot of great people, you learn a lot and it’s fun. Excited already? It gets better: the process is very open and getting involved in any of the steps is quite easy. In the next paragraphs we will explain how each of the steps work.

Testing
Testing Ubuntu can happen in a multitude of different ways. If you are adventurous you can upgrade to the newest development release of Ubuntu, but you can also download an Ubuntu image and take it for a ride. The Ubuntu Testing wiki pages not only explain how to test Ubuntu in a safe way, but also do they explain where you can submit your test results easily, be notified of new images and common test scenarios you might want to try out. If you don’t have a lot of development or QA experience: don’t despair – this is a great way to get involved, easy to do and very much worthwhile.

File bugs
If you encounter problems: file bug reports. The process for this is easy enough and requires for you just to explain yourself in a detailed way. Documenting each of the steps you took to run into the problem, what you expected to see instead and what the result was like is usually a good start. You obviously get bonus points if you check if the bug was already filed or if you can provide any kind of additional information (did the problem occur with a special file?) and the like. This step should be easy enough and is very important: don’t just assume that “the bug is surely filed already”.

Investigate the bug
If you are not afraid to get your hands dirty, this might be exactly the thing for you. Let’s say you are interested in a certain piece of software. Why don’t go and have a look at its newly filed Ubuntu bugs. Try to understand the problem at hand, verify that you can reproduce it, ask for more information if necessary. If the problem looks interesting to you, you might even want to go and have a look at the code and see if you can find out where the problem happens. If you prefer to stay well out of the code, you can still follow our bug triage steps to make sure the bug report is valid, has all the info it needs and is ready to get picked up by a developer.

Forward upstream
If it becomes clear to you that the bug is not only an Ubuntu problem, but also in the upstream project, you might want to consider forwarding it upstream. Obviously is it important to have all the relevant information in the bug report already and also important to find out if the bug was filed upstream already. One of the brilliant features in Launchpad (Ubuntu’s bug tracker) is that we can follow the progress on bug reports in other bug trackers by linking the Ubuntu bug to the upstream bug. Even conversation which happens upstream is imported easily. Some might consider this as “dumping work upstream”, but in fact forwarding is a worthwhile contribution. Most software authors appreciate that it is distributions who take their software out there and hearing back from their millions of users (if it is in a digested form), is good for their project as well. Obviously if we have a fix already, we should forward that as well. 😉

Pick up the fix
Let’s say you forwarded the bug report upstream and after a while you receive the mail that it was fixed upstream. Sometimes you will read some conversation about patches and if they are the right way to fix the problem, but sometimes will just receive a mail saying “fixed in r12345”, which loosely translated to “Thanks a lot for your detailed bug report. I took the time to fix it, and you can grab the fix at revision 12345 in our source repository.” As you can see, there is not only some slang you might want to learn, but also some detective work to be done: you might have to find the source repository and find out how to extract the changes of revision 12345. Once you have done that, it is a good idea to refer to it in the Ubuntu bug.

Integrate the fix
This is the stage where you finally can dip your feet into the source code. If you read a bit about Ubuntu development, have your development tools set up and learned how to apply a patch (or sometimes it might even be easier to update the package to the new upstream version), you can go ahead, build the package and test if the bug is truly fixed. This is a fun experience!

Propose for upload
This is a rewarding step as well: take the fix you either wrote yourself or got from upstream and propose it for upload. After a review of a fellow Ubuntu developer, it will get integrated into Ubuntu.

You can see how many different skills are needed and how many people work together to make the world a better place. Each of these steps has its challenges, there is a lot to learn, but most of all: it’s fun!

Let’s see how many of you follow the links above and get their hands dirty over the holidays!

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. Another option is to help out in one of our initiatives.

• Help out with fixing packages that don’t build anymore.
• Help out with security bugs.

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

Getting in touch

There are many different ways to contact Ubuntu developers and get your questions answered.

• Be interactive and reach us most immediately: talk to us in #ubuntu-motu on irc.freenode.net.
• Follow mailing lists and get involved in the discussions: ubuntu-devel-announce (announce only, low traffic), ubuntu-devel (high-level discussions), ubuntu-devel-discuss (fairly general developer discussions).
• Stay up to date and follow the ubuntudev account on Facebook, Google+, Identi.ca or Twitter.

Development Update

With holidays and the end of the year coming up soon, there is still lots going on, but there is not much on the release cycle plan which concerns us. 12th January, which is still four weeks away, will mark Debian Import Freeze, which will be a first gentle reminder to start solidifying instead of shaking things up again.

Update: Debian Import Freeze will be on 9th January. (Thanks Colin Watson)

If you want to know how all the individual teams are faring and what happened since last week, have a look at the release team meeting minutes, as always a great place to stay up to date. Another good place for more info is the status overview of blueprints and their work items: currently we 22% of our 2320 work items already sorted out.

Matthias Klose and many others have put a lot of hard work into making a complete rebuild of the Ubuntu archive happening. This happened as part of bootstrapping the armhf architecture. Very interestingly this brought up a couple of build failures that need to resolved. There is a list of general build failures and armhf/armel-specific ones.

The Desktop team just made a list of all the additional tasks they have and put out a call for help. So if you love your Desktop, want to make it even better, introduce yourself to them and find out what you can do!

Events

Ubuntu Developer Week
The planning of Ubuntu Developer Week (31st January 2012 to 2nd February 2012) is still going on and we should have something interesting to announce really really soon. If you always wanted to hear more about a specific topic, here’s your chance to let us know: leave a comment under the post to request your favourite topic.

Things which need to get done

If you want to get involved in packaging and bug fixing, there’s still a lot of bugs that need to get fixed:

• There’s Merges that need to be done (main, restricted, universe, multiverse).
• Also is the Ubuntu Mozilla team looking for help, so if you’re excited about Mozilla and what’s happening there, join IRC, talk to the guys on #ubuntu-mozillateam on irc.freenode.net.
• And then there’s Security bugs you can take a look at, the team is a friendly bunch and they’re incredibly helpful in getting your patch reviewed.
• There are bitesize bugs.

Also there’s a call for help from the Desktop team. Go check it out and see if you’d like to be part of the team!

Upload rights!

We have two Ubuntu developers who just got their upload rights approved by the Developer Membership Board: Micah Gersten, who just became Ubuntu Core developer and Julian Taylor who became MOTU.

Congratulations to the two of you, well-deserved!

Spotlight: Getting fixes into Ubuntu and getting upload rights

In terms of Ubuntu development one thing seems to remain a mystery to many: How do I a fix into Ubuntu? Even worse: I’m a mere mortal, can I get upload rights too?

There are many horror stories floating around regarding these two questions. “You need to work for Canonical.” being the worst answer to the above. Secret hand-shakes and bribes might be fun or appreciated, but it’s even easier than that.

Getting fixes into Ubuntu
A lot of the work in Ubuntu development is done using Bazaar, a distributed revision control system. What this basically means is: changes are easily identifiable and can easily be integrated from different development branches. With hundreds of developers, thousands of projects and different development focuses this makes perfect sense.

So how about our fix? First we branch the source code (get a local copy of it), edit it to fix the problem we identified, commit it locally, push it on Launchpad, then propose our branch for merging. Done. If you need more details about this, check out the article in the Packaging Guide.

There’s also the possibility to attach a patch file to a bug in Launchpad. You just need to make sure you subscribe the Sponsors team to the bug, to get the patch looked at.

It’s that easy. The Ubuntu developers have set up a schedule of “patch pilots” who regularly go through the list of open review items and tend to them.

Getting upload rights
Once you got a few fixes in and got a better understanding of Ubuntu development and the processes, you might get encouraged by your reviewers of peers in the Ubuntu community to apply for upload rights.

You have different options: if you are just interested in a package or two, because you love those packages or because you wrote them, you can just apply for upload rights for these. This is generally the easiest path. You need to demonstrate your level of involvement and dedication, have got a few uploads under your belt and a proper understanding of the relevant processes.

A lot of Ubuntu packages (not all) are categorised into “package sets”. Examples for these are “desktop”, “kubuntu”, “server”, “zope” and others. If you find yourself always working on the same packages which all are part of the same set, you might consider this option. Just remember: with greater power (immediate access to more packages), comes greater responsibility. This is not meant to discourage you, but just to make sure you meet all the requirements.

Two other options are MOTU and Ubuntu Core Developer: MOTUs (Masters of the Universe) have access to all the packages in Universe and Multiverse. Ubuntu Core Developers have access to every package in the archive.

The process for applying for upload rights is generally quite easy: document your work on the Wiki, send a mail to the Developer Membership Board (DMB) about it, attend a meeting, done. More details are available on the Wiki. The DMB obviously wants to make sure you know what you are doing and that you have a good enough understanding, but they are all likable people. So if you want to make sure you are a good fit, either talk to them or to one of your reviewers or peers beforehand.

Particularly the new options of getting upload rights for a package or package set are super-interesting for people with a narrow focus and good relations to upstream. Make use of these options! 🙂

Oh, and if somebody figured out the secret hand-shake, please let me know.

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. Another option is to help out in one of our initiatives.

• Help out with fixing packages that don’t build anymore.
• Help out with security bugs.

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

Getting in touch

There are many different ways to contact Ubuntu developers and get your questions answered.

• Be interactive and reach us most immediately: talk to us in #ubuntu-motu on irc.freenode.net.
• Follow mailing lists and get involved in the discussions: ubuntu-devel-announce (announce only, low traffic), ubuntu-devel (high-level discussions), ubuntu-devel-discuss (fairly general developer discussions).
• Stay up to date and follow the ubuntudev account on Facebook, Google+, Identi.ca or Twitter.