Ubuntu 12.04 Development update

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.