Ubuntu 12.04 Development Update 3

(This is a guest post from Ubuntu developer and Canonical employee Daniel Holbach, which was originally posted here.)

Ubuntu Development Update

Ubuntu Developer Summit is over and around 300 blueprints are being filled out with notes from the conversations of the summit. If you subscribed to a few blueprints, you might see updates over updates to get the work items in shape. As more and more of the blueprints get completed, you will also see status.ubuntu.com being filled up with mountains of work items. Thanks again everybody who participated in the sessions, in person or remotely. It’s great to see that level of cooperation and everybody’s willingness to contribute time and effort to make 12.04 an excellent release!

The development release is not very old yet, but we have seen heaps and heaps of updates in ‘precise': 1704 packages were uploaded since 13th October. That’s 117 great people who got their contributions into Ubuntu (in form of uploads) and there are going to be many many more. With a week of UDS in between, that’s pretty good. :-)

Although a number of Ubuntu developers still have their blueprints to finish until 24th November (Feature Definition Freeze), there is a lot of very active work going into fixing bugs and merging fixes from Upstream. Some of these are still going into 11.10 (‘oneiric’).

Also we would like to welcome three new Ubuntu developers who just gained upload rights: Herton Ronaldo Krzesinski, Stephen M. Webb and Serge E. Hallyn! Congratulations!

Thanks a lot everybody for your hard work! :-)

What is everybody doing now and in the few weeks?

There are two weeks left until Feature Definition Freeze and the week afterwards we will see 12.04 Alpha 1 get released. From there on it will be another four weeks (the end of the year) when we hit Debian Import Freeze. This will be the first milestone where the Ubuntu platform will start to solidify. The way a release cycle generally works is that in the first part all packages will be brought up to date. Ubuntu-local changes will have to be merged with changes that have happened in the meantime. The most favourable position as a package maintainer is to be able to “sync” the package from Debian. This means that the packages in Ubuntu and Debian are the same and without local changes, because it allows you to automatically let changes to be imported. If you introduced changes in Ubuntu, you have to make sure to send them over to Debian. All packages that are unmodified in Ubuntu will receive automatic updates from Debian ‘testing’ (‘testing’ because we are working on a LTS release, otherwise it’s ‘Debian unstable’) until Debian Import Freeze. Afterwards updates are still possible, but they have to be requested semi-manually.

All this explanation can be summed up like this: make sure upstream receives your Ubuntu fixes, work on bringing upstream and Ubuntu in sync in the first part of the release cycle. That’s what’s happening right now.

Events

Ubuntu Community Appreciation Day
This year we are going to have the first ever Ubuntu Community Appreciation Day. It is going to happen on 20th November and will remind us all that Ubuntu is put together by a lot of human beings, who put hours and hours of work in making this the best platform. Participating is easy: take the time to thank somebody who put a lot of effort into Ubuntu to make it shine. Tell your friends and participate!

Spotlight:lintian.ubuntuwire.org

So you set up lintian.ubuntuwire.org – can you explain what lintian is?
Sure. Lintian is a tool developed within Debian for evaluating packages. It’s mostly used to make sure that packages are compliant with Debian Policy – the rules for how packages can best integrate with the rest of the system – but Lintian has been known to catch other small mistakes as well. My favorite examples of that are the spelling error tags, such as http://lintian.ubuntuwire.org/tags/spelling-error-in-description.html, which has been known to catch plenty of my own misspellings in the past!

How do you think Ubuntu developers should use this resource?
For most of us, the tools we use for test-building packages already include Lintian output, so hopefully we’re already aware of Lintian problems in packages we modify. I think presenting the information in a web form is most useful for evaluating the overall health of the archive. Going forward, I’d like to generate reports based on packages which only exist in Ubuntu, or packages where our modifications have introduced new Lintian errors and warnings. For new contributors, Lintian’s output tends to have very focused information about where the problem is. Since Lintian tags are generally about issues with packaging, I think that correcting Lintian tags can be a great way to learn your way around packaging in general.You mention new contributors – how could they make use of this resource? If somebody wanted to go and improve packages, could they make use of this site?
Lintian has a concept of “severity” – how bad a problem is – and “certainty” – how confident it is that it’s not emitting false positives. One of the reports generated on lintian.ubuntuwire.org groups tags by their severity and certainty (http://lintian.ubuntuwire.org/tags-severity.html). The higher the degree of certainty, the easier it is for Lintian to understand the problem – and that means it’s probably easier for a new contributor to understand the problem as well! I would recommend picking a package with a high certainty tag, and trying to fix that. If you fix it, you can work with Debian on incorporating the fix. Because Lintian tags cover Debian Policy violations, they’re generally uncontroversial. Stop by in #ubuntu-motu on IRC, and we can help you pick one.

Thanks a lot for putting the site together!
Sure! I hope that people find it a useful tool for improving the quality of Ubuntu … and Debian. :-)

Spotlight 2: Ubuntu Development? What is it exactly?

There is a lot of talk about Ubuntu Development and always has been. Sometimes it was about hacking on internals of the Ubuntu OS, there was talk about fixing bugs in Ubuntu and sometimes there was talk about apps in Ubuntu. If you haven’t been involved much, chances are that you got confused a number of times.

It’s a complicated world, there’s Ubuntu, there’s packages, there’s apps, there’s other projects such as Debian and other Upstreams. Here’s my try to bring in a big more clarity to the picture.

Ubuntu Platform. This is what you get when you install Ubuntu. It comes in many forms such as the Ubuntu Desktop, Ubuntu Server, Kubuntu, Xubuntu, Lubuntu and others. All these different forms share the same thousands of packages, which contain tools, libraries and programs. They are part of the same Ubuntu archive.

Ubuntu does not live in a separate world, but is part of the wider Open Source community. There are many Open Source projects the Ubuntu Platform relies on and where its developers actively participate in. These projects release code which gets integrated in Ubuntu, they are called ‘Upstreams’, as their code flows into Ubuntu.

The great thing about the Ubuntu Platform is that it is open and is development in a transparent fashion. Everybody can check out the source code, find out about what was changed exactly. Furthermore everybody can get involved and help out making the platform even better. If you are interested in making Ubuntu better generally or take interest in a specific area of Ubuntu, we want you to contribute.

Ubuntu Apps. These are third-party applications which we are keen to have available in Ubuntu. It should be easy and fun to write apps that blend into and work in Ubuntu nicely. The requirements are less strict, for example is it not necessary for these apps to exactly follow the Ubuntu release cycle. With developer.ubuntu.com a great portal was put together which helps understand the technologies and how to get them included in Ubuntu.

If you are interested in writing your own app and get it into Ubuntu, we want you and your apps in Ubuntu!

Get Involved

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.

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.

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.