Category Archives: MOTU

Parabéns e muito obrigado!

3 Replies

I’m particularly happy to announce that the Brazilian team managed to get their translation of the Ubuntu Packaging Guide up to more than 70% of completion, which is the magic threshold to get it accepted and posted on developer.ubuntu.com. This means that our current list of available languages is:

  • English
  • Spanish (99%)
  • Russian (85%)
  • Brazilian Portuguese (74%)

You can view the individual forms of the Packaging Guide in Brazilian Portuguese here:

Right at the start I said that I was “particularly happy” about this translation. That’s because I recently picked up a little bit of Portuguese. Mostly useful sentences like “Meu irmão gosta de cerveja” or “O leão escreve cartas”. Thanks Duolingo!

A big big big “obrigado” to the tireless Brazilian Portuguese translators. You all are heroes! This is great news for everyone who wants to get involved in Ubuntu development, as it smoothes the first steps considerably.

You can help out with translations. Just head to the Packaging Guide’s translation page in Launchpad, pick your language and get started. Current runners-up to the translations mentioned earlier are:

  • German (32%)
  • Japanese (15%)
  • French (7%)
  • Indonesian (5%)
  • Dutch (4%)

The available translations are not entirely complete yet either, so please do get involved.

The Packaging Guide finally does speak Spanish

4 Replies

We have achieved a huge milestone in the development community. For years we wanted translatable packaging and development documentation. It’s there. If you head to http://developer.ubuntu.com/packaging/ you can see the following:

The Ubuntu Packaging Guide (Spanish) – would you like to learn how to package or become an Ubuntu Developer? Here’s a comprehensive, topic-base guide that explores and describes the main concepts of packaging. It is available as

This is absolutely awesome. From now on we will be able to add languages and have up-to-date Packaging and Development docs available whenever they are complete enough.

This work was brought to you by many people who worked very hard to get all the bits right, both on the packaging, integration, beautification and translations sides. You all know who you are. Be proud of your work. This will ease the steps of many people into helping out with Ubuntu!

As always this is ongoing work and the great thing is, you can help out:

This makes me a very happy man and it’s great we finally got there. Now let’s get all the other translations up to scratch! :-D

Packaging Guide: Hablamos español.

8 Replies

One group in Ubuntu which never gets the credit they deserve are the translators. These fine people spend hours smoothing the road for Ubuntu into all the parts of the world. One project where this recently became clear to me again was the Packaging Guide.

Weighing in at 759 strings or 196K of text, and at times very technical text, it’s probably not the easiest document to translate. Still we have a very nice success story to share.

The Spanish team got their translations up to 95% completion. Incredible work! Muchas gracias! The other teams were busy as well, so we have:  Brazilian Portuguese (22%), Japanese (17%), Russian (9%), German (9%), Dutch (3%), along with other teams which are just getting started: Vietnamese, Macedonian, Swedish, Turkish, Indonesian, French, Latvian, Chinese (Traditional), Slovenian, Hungarian and Catalan.

This means that Spanish is the first language which made it past out magic threshold and will soon ship separate packages for the guide in Spanish. Fantástico!

I said “soon” because we are still working out a couple of kinks to do this in the easiest fashion. Thanks to help of many we figured out the following problems:

But we are still struggling with the following ones:

So if you are knowledgeable in this area, please consider helping out.

Thanks everyone for your stellar work on this. You make the lives of new contributors a lot lot easier!

Bringing new developers up to scratch

4 Replies

I talked many times about getting involved with developing Ubuntu and how it can seem daunting and that there’s much to learn. When I talked to contributors who had reached the critical point where they understood what they can do, who they can talk to and how the processes roughly work, most of them said that three things helped them to get to the point:

Code review

Today I want to talk about code reviews. It’s probably the most straight-forward way to learn by osmosis: you easily pick up conventions, distinctions which are made and which processes to follow.

Everybody has to go through code reviews, no matter which team they are in, which company they work for or when they joined the project. Up until a point they get their developer application approved and get upload rights.

This is the reason why code reviews in Ubuntu are so important and why we should constantly strive for timely replies and decisions on review requests.

Sponsoring Queue

The sponsoring queue is reviewed by developers with upload rights. Sometimes it’s very easy to approve a request and upload the package, sometimes it takes a bit longer, especially when you have a comment ping-pong between the reviewer and the patch author.

We came up with a number of points in our documentation which should help keeping the queue manageable:

For Bugs fixing small details, you could do the following:

  1. Ask the contributor to forward the patch upstream.
  2. Open an empty upstream bug task.
  3. Mark the Ubuntu task as ‘Fix Committed’.
  4. Unsubscribe ubuntu-sponsors, or mark the merge proposal status as “Work in Progress”. (Be sure to tell the contributor to reverse the process.)

This will get the review item off the list for the time being and once we can import the code from upstream, it will get fully closed.

We also get requests which are not suitable for the current release period. In this case you could:

  1. Let the contributor know that the patch is not suitable for the current release period.
  2. Unsubscribe ubuntu-sponsors, or mark the merge proposal status as “Work in Progress”. (Be sure to tell the contributor to reverse the process.)
  3. Subscribe yourself to the bug report.
  4. Milestone the bug to ‘later’.
  5. Visit https://bugs.launchpad.net/people/+me/+bugs/?field.milestone%3Alist=196 once the new release opens and upload the fix.

This are just some points which help to keep things on the queue relevant.

Patch Pilots

From the Bazaar team we borrowed the scheme of “patch pilots”. Here’s how they explain how it works: “The word pilot is in the sense of a maritime pilot: we help patches come through congested waters safely in to harbour. The main thing to watch is the bzr active reviews page in Launchpad. When you’re piloting, put some concentrated effort into helping people have a good and satisfying experience contributing to Bazaar. Just how you do that is up to you.

Instead of trying to review each and every bit in the queue – sometimes there are packages you know less about and where you can’t make a decision for example – you try to help nudge the patch along. You help to talk to upstream about it, try to find somebody who can make a decision, etc.

Canonical engineers with upload rights who work on Ubuntu are expected to spend an hour per week on the Ubuntu sponsoring queue, so everybody’s on the hook for having a piloting shift 4h every four weeks. This usually works much better, as you have an extended period of time where you do nothing else. Current patch pilots can be seen in the #ubuntu-devel channel topic.

Up until now I mostly noticed Canonical engineers who did piloted. If you have upload rights and are interested, let me know and I can add you to a preliminary schedule, so you get a reminder mail and you can try it out and see if you like it.

Please all help making this work even better. :-)

Ubuntu Packaging Guide has finally landed

10 Replies

Users of Ubuntu 12.10 (Quantal Quetzal) now can easily install the Ubuntu Packaging Guide:
daniel@daydream:~$ sudo apt-get install ubuntu-packaging-guide
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
ubuntu-packaging-guide-html
The following NEW packages will be installed:
ubuntu-packaging-guide ubuntu-packaging-guide-html
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/488 kB of archives.
After this operation, 1244 kB of additional disk space will be used.
Do you want to continue [Y/n]?
Selecting previously unselected package ubuntu-packaging-guide-html.
(Reading database ... 238890 files and directories currently installed.)
Unpacking ubuntu-packaging-guide-html (from .../ubuntu-packaging-guide-html_0.2.2_all.deb) ...
Selecting previously unselected package ubuntu-packaging-guide.
Unpacking ubuntu-packaging-guide (from .../ubuntu-packaging-guide_0.2.2_all.deb) ...
Processing triggers for doc-base ...
Processing 1 added doc-base file...
Registering documents with scrollkeeper...
Setting up ubuntu-packaging-guide-html (0.2.2) ...
Setting up ubuntu-packaging-guide (0.2.2) ...
daniel@daydream:~$

Of course you can always browse it online here but for all offline use it is now in Ubuntu in PDF, HTML and EPUB formats.

This was only possible through the help of many contributors. Some of them I was able to get together from the bzr log:

  • Alexander Fougner
  • Andrew Starr-Bochicchio
  • Barry Warsaw
  • Benjamin Drung
  • Brian Murray
  • Daniel Holbach
  • Dmitry Shachnev
  • Iain Lane
  • Jamie Strandboge
  • Jelmer Vernooij
  • Jeremy Bicha
  • Jim Campbell
  • Jonathan Jesse
  • Jonathan Riddell
  • Joseph Mills
  • Leo Iannacone
  • Martin Owens
  • Raoul Snyman
  • Ryein
  • Stefano Rivera

Thanks so much for your great work in the Ubuntu Packaging Guide project – you are all heroes!

There is still lots of work to be done. If you want to get involved, because it’s a really nice project, have a look at a list of bugs and please help to get it translated!

You can help: code review

1 Reply

This morning I woke up and found the sponsoring queue at 103 items! I mailed the ubuntu-devel and ubuntu-motu lists and the current count is down to 81. This is great, but I’m sure we can get it down to 0.

Jani Monoses also filed these bugs to discuss how we can improve our sponsoring strategy:

You might want to join the conversation.

What we need most though is that if you can review code and upload changes, you head over to the sponsoring queue and help reviewing. It’s understandable that after UDS everybody is busy doing merges or jumps head-first into work items, but we also need to help newcomers get their changes reviewed. If you need some help, review our sponsorship best-practices.

If you should want to help on a regular basis, ping me or drop me an email and I’ll add you to the patch pilot schedule and you’ll get monthly reminders.

Rock on everybody! We can be happy we have so many new contributors, let’s don’t let them down! :-)

UDS is a great time…

5 Replies

… for planning things, but also for getting things done.

In-between sessions I had discussions with many many folks and I’m happy to say there was renewed and much interest in the Packaging Guide.

Heroes like Andrew Starr-Bochicchio, Leo Iannacone, Joseph Mills and others have contributed suggestions, code, ideas and text bits to improve the packaging guide, and that’s on top of what was discussed in the session we had.

During the session we identified a number of areas of focus. In no particular order, there’s:

  • Include the Packaging Guide in Ubuntu
  • Translate it in as many languages as possible
  • Merge the Wiki documentation into the guide
  • Do user-testing of the guide
  • Do an editorial review of all the content

Also in many other sessions, the Packaging Guide was usually deemed the best place to educate new contributors about how things work, which is great.

What happened this week (outside of sessions) already was:

This level of activity is fascinating and bodes well for a great 12.10 cycle.

What I love most about the guide is that everybody can help us if you have just a little bit of interest in Ubuntu Development. Let’s have a quick look at some bugs you could help out with, if you’re interested.

Here’s some ‘bitesize’ bugs, I hope we can you interest in:

Obviously, there’s more bugs and there’s a blueprint to subscribe to. Feel free to grab a bug and help out, or catch us on IRC and find out how you can get involved.

Update: I forgot to mention John Kim, who has contributed a bunch of bug reports with his experience. Great work, John!

What new development contributors have to say

1 Reply

One class of new contributors has always been successful: self-starters who knew what they wanted to do, where to get involved, with possibly some already existing experience or knowledge. For others it’s been a tougher ride.

To remedy some of this, we set up the Developer Advisory Team. We figured that (among other things) reaching out to new contributors who just got their first fix into Ubuntu to thank them, encourage them and ask for their feedback would help us a lot in terms of bringing them into the fold and finding out what current stumbling blocks are.

The team consists of Andrea Colangelo, Andrew Starr-Bochcchio, Bhavani Shankar, Christophe Sauthier, Evan Broder and myself. We’ve been working together for a few weeks now and been reaching out to many contributors to Ubuntu development.

We collected the feedback and put together a report which summarises the experience of new contributors. If you’re in the thick of process definitions, documentations, backlog of review queues and the like it’s very easy to only concentrate on things which are broken or could be improved.

I’d like to take the time to quote a few of the super positive responses we received:

  • “Developers always respond very friendly.”
  • “I’m also very much impressed by the smoothness of online collaboration through launchpad and bzr (wow, would not have thought I’d be praising bzr at some point ). Branching a project to fix a bug and getting that visible to the project’s developers is effortless and lets me concentrate on the actual work.”
  • “Had heard about reviews taking a long time, but didn’t find it to be the case.”
  • “I really enjoyed getting to see my contributions go through the whole cycle from inclusion to available update. Seeing the process was interesting, as I had not known the different stages previously, and it was exciting to realize that a bug fix (simple, but there nonetheless) could go from a proposed fix to being available for installation in just over 24 hrs.”
  • “Much easier than I had expected. I had always assumed that one had to be an official packager to apply a patch to a package and submit it. Overall, it was a surprisingly painless process.”
  • “I think the most positive part of the experience to date has been the realization that the Ubuntu community cares enough to engage in this kind of feedback solicitation. That is simply unparalleled in other projects, and a testament to the many solid reasons so many prefer Ubuntu.”
  • “Overall, the entire was quite enriching and engaging. To be frank, I was desperately waiting for an opportunity to fix an easy bug for quite some time. And, so when I eventually found one, I was overly joyed. Given another opportunity, I will surely contribute again to Ubuntu development.”
  • “The people. Good response from other people, great impression about the whole community.”
  • “Contributing to free and open source projects makes me excited. It is great that I can paticipate and improve Ubuntu. I feel awesome when my work is released. Also I was glad when people found out their problem doesn’t exist in new release.”

Everybody who helps make this happen on a daily basis: give yourself a pat on the back. I’m proud of what we achieve together, and so should you! :-)

Check out the full report if you want to get into the details of the feedback.

If you have comments yourself or suggestions for improvements, leave your comment below.

If only I had known what needs to be done…

14 Replies

I just went over the soon-to-be-released report of the Developer Advisory Team, where we sum up feedback from first-time contributors to Ubuntu Development and many noted that they found developer documentation easily and things generally worked out for them, but they struggled finding stuff to work on.

The Ubuntu Development team has always been good at creating new TODO lists (merges, Debian RC bugs, build failures, heaps of different bug lists and much much more), but you need to know what you are looking for.

Enter Harvest. We created it so it merely aggregates opportunities for Ubuntu developers in a simple web interface. You can select opportunity types and specific sets of packages to narrow down opportunities based on your interests.

If you got some spare time, are interested in Ubuntu development and would like to help, you would do the Ubuntu world a great favour by doing one of the following:

If you are an Ubuntu developer or would like to become one: trying it out and commenting below with your experience. (Bugs can be filed here.)

If you have a great idea on how it could be further simplified, extended or improved, write up your idea and link to it in the comments.

If you are a web developer: please get in touch. Harvest is written using Django and Python and it’s super-easy to extend, improve and fix it – so if you are looking for something to help out with, this might be a great opportunity for you.

Please consider helping out, your contributions will not only help you make better use of Harvest, but many other developers and new contributors as well. :-)

(If you tried it out and it works perfectly for you, let us know too. :-) )

Making sure code gets reviewed in Ubuntu

1 Reply

New contributors who don’t have upload rights to Ubuntu yet get their code reviewed and their packages uploaded by Ubuntu developers. This process is called “sponsoring” and our current process has been in place since pretty much forever. It has even gotten easier over time, so new branches or patches show up on our review queue.

Two years ago when we were struggling with getting code reviewed, we put in place “patch pilots”, a great concept we borrowed from the Bazaar team. We set up a monthly schedule and Canonical provided 4 hours per month per engineer with upload rights to make sure code gets reviewed. This has helped a lot.

Getting closer to the 12.04 release, it looks like we need to put some extra effort in and need some help.

Sponsoring Stats

That’s right we have been hovering around 50 for a while now, dealt with many incoming new requests, but still we don’t get down to 0. If you can review code, please help out.

We all are interested in getting new developers on board. This only works if we review each other’s work, gain each other’s trust and give each other advice.

The Sponsorship queue is where a lot of exchange about this happens and where knowledge is passed on. Help out by reviewing today and help grow our community this way.

This is one of the most valuable contributions to Ubuntu! This matters to all of us.

If you want to see at once glance how we are doing and who’s all helping out, head over to our one glance sponsoring page. (Patches to make it look more Ubuntu-y are very welcome!)

Check the instructions for code review (with lots of tips and tricks) and get your name on the page as well!