Canonical Voices

Posts tagged with 'developers'

Daniel Holbach

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

Read more
Daniel Holbach

Jono blogged about the importance of application developers to Ubuntu earlier and I wanted to echo some thoughts and add some of my own.

I have been in the Ubuntu Developer camp for most of Ubuntu’s life as a project, so the mindset of “App developers? Why don’t they just set up an open source project and get it packaged?” or “Apps? We have packages.” is what I have heard a couple of times already and is what I would probably have answered some years ago myself.

The power of the Open Source community and having open projects is immense. We all have seen it many times: a thought, a great idea, some dedicated contributors, good communication and a friendly community can achieve amazing things. This happens every single day.

We are well aware of how things work in the Open Source world and we have recently seen the success of our great work: millions of users, who have never dabbled in Open Source before, today enjoy Ubuntu (or other pieces of Free Software) and rely on it. We have managed to reach out to an entirely new demographic and continue to grow our user base.

With new demographics there are new expectations and new responsibilities. Consider my father for example. He follows what’s going on in the Ubuntu world, but will occasionally point out to me that an app he’s interested in buying does not exist for Ubuntu. The last I remember him talking about was a good language learning course.

With new form factors and devices running Ubuntu (you know, TVs, tablets, phones, watches, cars, coffee machines, hoverboards and the like), there are going to be thousands of useful helper tools out there which might not be available for Ubuntu yet. Add to that the growing number of content providers (magazines, books, maps, music, etc.) which users yet can’t easily get “for Ubuntu”.

This is the world we are looking at today and it becomes obvious that apps should be a first-class citizen in Ubuntu. Don’t get me wrong. I’m all for making everyone who shows the slightest interest in working on Ubuntu itself an Ubuntu developer and member of our community, also because I feel that everyone who is part of this has a lot to gain, personally and for their particular project. It just shouldn’t be a strict requirement because it won’t scale.

A number of teams have been working very hard on making seamless apps in Ubuntu a reality and that’s just great to see. It’s a hard problem to solve because it involves so many different important pieces. Keep up the good work everyone!

At UDS I’m definitely going to (among other sessions, I’ll blog about later on) attend these sessions to see what we can do about making apps in Ubuntu more exciting and something that just works:

Hope to see you there!

Read more