...we hack together with you...

...on Ubuntu.

It's no Rocket Science...

...but rather a lot of fun!

Join us and...

...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.

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.

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!

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!

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:

• Update CSS of Packaging Guide to be in sync with developer.u.c (CSS gurus, please step forward)
• be explicit about installing packages from universe in getting-set-up
• apt-cache included in basic packaging software section
• Diagrams could be a bit more Ubuntu-y
• Mention http://screenshots.debian.net/upload in the packaging-from-scratch sections
• Please add to the footer a link how to propose fixes/changes to the guide.
• Advertise ‘setup-packaging-environment’ in getting-set-up article
• contributers ? contributors

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

• Need a Quick Start Guide
• Add article about “Updating package versions”
• Add article “Python packaging”
• Add article explaining how to work with Debian/Upstream
• Add article that explains how to use Launchpad and Bugs
• Short article that explains PPA best practices

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

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.

Please 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!

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?

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!

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:

• 28906 “init script starts before NFS, NIS, DNS (need two stages)“
• 785052 Update whois server for “.*.ua” zones
• 773141 Playing with options in CCSM can break Unity
• 791467 bump gcdmaster dependency on cdrdao to 1:1.2.3-0.1ubuntu2
• 769405 AppleDouble files present in the package

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.

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.

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”.

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.

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.

$ apt-file find /usr/bin/tomboy

tomboy: /usr/bin/tomboy

$ apt-cache show tomboy | grep ^Source:

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

$ patch -p1 < ../bugfix.patch

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

$ dch -i

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

debcommit

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

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

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

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.

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

$ gpg --gen-key

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

$ gpg --send-keys <KEY ID>

$ ssh-keygen -t rsa

COMPONENTS="main universe multiverse restricted"

$ pbuilder-dist <release> create

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

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

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

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

$ source ~/.bashrc

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.

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:

• to contribute a change to Ubuntu, read the docs about the sponsorship process
• to help patch piloting, check out the docs about code review in Ubuntu

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

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.

This cycle’s Ubuntu Developer Week is over. I know it’s unfortunate, but I hope you all had as great a time as I did. Logs are up on the Ubuntu Developer Week page, so if you want to check out what happened during the week, just go and read what happened.

Here’s the summary of the last day, Friday:

1. Getting better bug reports: The day kicked off with Brian Murray and Nigel Babu, who explained how to use and extend Apport for packages that you are interested in. Seriously good stuff that prevents a lot of bug conversation ping-pong.
2. Introducing boto EC2 Cloud API: Ahmed Kamal did a terrific job of explaining the boto EC2 Cloud API. It’s simple, easy to use and super useful whatever you might want to get done.
3. Introduction to Django Development: ?ukasz Czy?ykowski was up next and gave an excellent session explaining how to get started using Django for developing websites. He zipped through an interesting and small example that showcases how beautiful and powerful Django is.
4. Getting started with daily builds in Launchpad: I’m glad we had Micha? Zaj?c (and Philip Muškovac) giving a session about Daily Builds in Launchpad. A super-helpful service that will give you latest upstream goodness to play with in a very pain-free way.
5. Project Lightning Talks: This was an experiment, but I’m quite sure that it’s here to stay. It was quite exciting to learn about loads of new projects that are going on. So if we can give all of them a platform for introducing themselves and attracting new users and contributors, we should definitely do that. Check out the log – seriously good stuff!

Ubuntu Developer Week might be over for this cycle, but there’s always the next UDW and there’s loads of ways to get involved beforehand.

It’s a shame, I know, but unfortunately it’s true: Ubuntu Developer Week is almost over. We rushed through 4 days in no time now and today is the last day.

If you couldn’t make it yesterday, don’t despair: we have logs and here’s the quick summary of what happened:

1. Integrating your package with Launchpad Translations: David Planella kicked off the day and gave a sterling session on getting most out of Launchpad’s Translations goodness in a pain-free and fun way.
2. Getting Started with Unity 2D: We started with 5 minutes delay, but the session was entirely worth the waiting time. Florian Boucault gave a great session explaining the foundations of Unity 2D, the plans and how to get involved.
3. Q+A with Ubuntu Engineering Director: A super interesting session with everyone’s favourite Rick Spencer. Rick got quite a bunch of good questions, so check out the log and find out what Rick does and how things work out in Ubuntu development.
4. Getting your app into Ubuntu (Post-release): Stéphane Graber is a member of the Application Review Board (ARB) and so he was in the perfect position to explain how the process works, what the requirements are and how to bring fun apps to Ubuntu.
5. Good stuff in ubuntu-dev-tools: Benjamin Drung did an awesome job explaining our favourite toolset and the gems hidden in it. Check out the log, make good use of them and maybe you want to add your own tools to it?

As I said above: today is the last day and it’s action-packed. Let’s see what’s going on today:

• 16:00 UTC: Getting better bug reports — nigelb and bdmurray: Developers will get to know about getting quality bug reports by writing apport hooks for applications so that basic information will always be collected
• 17:00 UTC: Introducing boto EC2 Cloud API — kim0: Learn Amazon cloud 101, how to run and control cloud instances of Ubuntu server from python
• 18:00 UTC: Introduction to Django Development — lukasz: Short introduction to creating web applications using Django framework.
• 19:00 UTC: Getting started with daily builds in Launchpad — Quintasan: Micha? Zaj?c will introduce you to Recipe magic in Launchpad, working pbuilder and Launchpad account is more than welcome
• 20:00 UTC: Project Lightning Talks: 5 minutes each to introduce your project
  • Stéphane Graber, arkose (desktop application sandboxing)
  • Keimpe de Jong (UndiFineD), SpeechControl (an accessibility program to control computer, by voice and other input types)
  • Dustin Kirkland, Bikeshed (All those handy scripts)
  • Alan Bell, Meetingology a new meeting and minute taking IRC bot
  • Michael Hall, XDG Launcher (XDG-Menu panel)
  • Jason Gerard DeRose, Distributed Media Library (aka dmedia)
    
  • Michal Zajac, Philip Muškovac and Rohan Garg, Project Neon, a.k.a daily builds of KDE and related

We’re deep into Ubuntu Developer Week now. 15 sessions have already happened, 10 are still to come. I don’t know about you, but I had a fantastic time up until now.

Let’s zip through yesterday and see what happened:

1. TestDrive: First of the day was Andres Rodriguez who talked about TestDrive and how to make use of it for testing and toying around with various Ubuntu (and other Linuxes’) releases. Andres also tried to settle the question where Pisco was originally invented.
2. LoCo Directory Hacking: An awesome session delivered by Michael Hall about loco.ubuntu.com and how it is developed. If you are into web development, would like to see more LoCos use the service, check out the logs and get involved.
3. Ubuntu ARM and the OMAP4 images: Next up was Oliver Grawert who gave a great introduction into what’s happening in ARM land right now and how Ubuntu developers are putting great work into porting everything necessary. His classy answer to the question of “arm?” was “yes ”.
4. Developing IRC bots: Terence Simpson gave a session about IRC bots, how they are used, how to implement a bot, etc. A really insightful and interesting session. Also he actively contradicted me: it seems he didn’t start hacking on IRC bots when he was 5, probably closer to 6.
5. Rocking out with libunity: Mikkel Kampstrup had the last session of the day and gave a well-structured and nicely prepared session, explaining how to interact with Unity, add places and integrate with the launcher. Super interesting stuff. I hope people make great use of it soon.

Today is day 4, let’s see what it has in store for us today.

1. 16:00 UTC: Integrating your package with Launchpad Translations: First session of the day is lead by David Planella who will explain how to make hook up with Launchpad and make use of all the juicy translations your translator community provides.
2. 17:00 UTC: Getting Started with Unity 2D: Florian Boucault is up next and will talk about the 2D version of Unity, written using Qt. An excellent project to get involved with. If you’re into Qt, make sure you’re there.
3. 18:00 UTC: Q+A with Ubuntu Engineering Director: Rick Spencer will run a question and answer session about the Ubuntu Platform, what’s happening and what future plans might be. Come in masses, bring your questions!
4. 19:00 UTC: Getting your app into Ubuntu (Post-release): Stéphane Graber will lead a super-interesting session about the App Review board and how to get applications into Ubuntu post release.
5. 20:00 UTC: Good stuff in ubuntu-dev-tools: Did you ever find yourself in the situation where somebody tells you about a tool that exactly does what you need and you just had never heard of it before? Prepare for a session of constant “A-Ha moments”. Benjamin Drung will show you what you can find in ubuntu-dev-tools.

Excellent line-up, I’d say: let’s get cracking!