Here’s what you need to do:
- Read the first few articles.
- Join us in #ubuntu-motu on irc.freenode.net on Friday.
- Have fun and start making Ubuntu better!
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.Read more
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!Read more
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):
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!Read more
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:
Here is a list of bugs that would be great to have fixed:
And here is a list of articles that still need to be written:
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:
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!Read more
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?Read more
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:
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:
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!Read more
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:
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.
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:
Pick a bitesize bug. These are the bugs we think should be easy to fix. Here’s a few examples:
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.Read more
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.
I’m very excited about this project and feel the quality of it is getting better and better.Read more
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:
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
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”.Read more
I just set up a daily build for the Ubuntu Packaging Guide. To get the latest goodness, simply:
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.Read more
The article below is all about fixing bugs in Ubuntu.
If you followed the instructions to get set up with Ubuntu Development, you should be all set and ready to go.
As you can see in the image above, there is no surprises in the process of fixing bugs in Ubuntu: you found a problem, you get the code, work on the fix, test it, push your changes to Launchpad and ask for it to be reviewed and merged. In this guide we will go through all the necessary steps one by one.
There is a lot of different ways to find things to work on. It might be a bug report you are encountering yourself (which gives you a good opportunity to test the fix), or a problem you noted elsewhere, maybe in a bug report.
Harvest is where we keep track of various TODO lists regarding Ubuntu development. It lists bugs that were fixed upstream or in Debian already, lists small bugs (we call them ‘bitesize’), and so on. Check it out and find your first bug to work on.
If you don’t know the source package containing the code that has the problem, but you do know the path to the affected program on your system, you can discover the source package that you’ll need to work on.
Let’s say you’ve found a bug in Tomboy, a note taking desktop application. The Tomboy application can be started by running /usr/bin/tomboy on the command line. To find the binary package containing this application, use this command:
$ apt-file find /usr/bin/tomboy
This would print out:
Note that the part preceding the colon is the binary package name. It’s often the case that the source package and binary package will have different names. This is most common when a single source package is used to build multiple different binary packages. To find the source package for a particular binary package, type:
$ apt-cache show tomboy | grep ^Source:
In this case, nothing is printed, meaning that tomboy is also the name of the binary package. An example where the source and binary package names differ is python-vigra. While that is the binary package name, the source package is actually libvigraimpex and can be found with this command (and its output):
$ apt-cache show python-vigra | grep ^Source: Source: libvigraimpex
Once you know the source package to work on, you will want to get a copy of the code on your system, so that you can debug it. This is done by branching the source package branch corresponding to the source package. Launchpad maintains source package branches for all the packages in Ubuntu.
Once you’ve got a local branch of the source package, you can investigate the bug, create a fix, and upload your proposed fix to Launchpad, in the form of a Bazaar branch. When you are happy with your fix, you can submit a merge proposal, which asks other Ubuntu developers to review and approve your change. If they agree with your changes, an Ubuntu developer will upload the new version of the package to Ubuntu so that everyone gets the benefit or your excellent fix – and you get a little bit of credit. You’re now on your way to becoming an Ubuntu developer!
We’ll describe specifics on how to branch the code, push your fix, and request a review in the following sections.
There are entire books written about finding bugs, fixing them, testing them, etc. If you are completely new to programming, try to fix easy bugs such as obvious typos first. Try to keep changes as minimal as possible and document your change and assumptions clearly.
Before working on a fix yourself, make sure to investigate if nobody else has fixed it already or is currently working on a fix. Good sources to check are:
If you find a patch to fix the problem, say, attached to a bug report, running this command in the source directory should apply the patch:
$ patch -p1 < ../bugfix.patch
Refer to the patch(1) manpage for options and arguments such as --dry-run, -p<num>, etc.
To build a test package with your changes, run these commands:
$ bzr bd -- -S -us -uc $ pbuilder-dist <release> build ../<package>_<version>.dsc
This will create a source package from the branch contents (-us -uc will just omit the step to sign the source package) and pbuilder-dist will build the package from source for whatever release you choose.
Once the build succeeded, install the package from ~/pbuilder/<release>_result/ (using sudo dpkg -i <package>_<version>.deb). Then test to see if the bug is fixed.
It is very important to document your change sufficiently so developers who look at the code in the future won’t have to guess what your reasoning was and what your assumptions were. Every Debian and Ubuntu package source includes debian/changelog, where changes of each uploaded package are tracked.
The easiest way to do this is to run:
$ dch -i
This will add a boilerplate changelog entry for you and launch an editor where you can fill out the blanks. An example of this could be:
specialpackage (1.2-3ubuntu4) natty; urgency=low * debian/control: updated description to include frobnicator (LP: #123456) -- Emma Adams <firstname.lastname@example.org> Sat, 17 Jul 2010 02:53:39 +0200
dch should fill out the first and last line of such a changelog entry for you already. Line 1 consists of the source package name, the version number, which Ubuntu release it is uploaded to, the urgency (which almost always is ‘low’). The last line always contains the name, email address and timestamp (in RFC 5322 format) of the change.
With that out of the way, let’s focus on the actual changelog entry itself: it is very important to document:
- where the change was done
- what was changed
- where the discussion of the change happened
In our (very sparse) example the last point is covered by (LP: #123456) which refers to Launchpad bug 123456. Bug reports or mailing list threads or specifications are usually good information to provide as a rationale for a change. As a bonus, if you use the LP: #<number> notation for Launchpad bugs, the bug will be automatically closed when the package is uploaded to Ubuntu.
With the changelog entry written and saved, you can just run:
and the change will be committed (locally) with your changelog entry as a commit message.
To push it to Launchpad, as the remote branch name, you need to stick to the following nomenclature:
This could for example be:
So if you just run:
bzr push lp:~emmaadams/ubuntu/natty/specialpackage/fix-for-123456 bzr lp-open
you should be all set. The push command should push it to Launchpad and the second command will open the Launchpad page of the remote branch in your browser. There find the “(+) Propose for merging” link, click it to get the change reviewed by somebody and included in Ubuntu.
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.
There are a number of things you need to do in the beginning to enable you to do Ubuntu development. A few of them you have to do locally on your system. In addition to that you also need to inform Launchpad about yourself, so it accepts changes you want to make.
When you followed all the steps in this article,
It is advisable to run the current development version of Ubuntu. It will allow you to test changes in a “live environment” where they are actually built and tested in the development release you upload them to.
https://wiki.ubuntu.com/UsingDevelopmentReleases shows a variety of ways to use the development release in a safe way.
There are a number of tools that will make your life as an Ubuntu developer much easier. You’ll encounter these tools later in this guide. To install most of the tools you’ll need, run this command:
$ sudo apt-get install gnupg pbuilder \ ubuntu-dev-tools bzr-builddeb apt-file
These packages include:
GPG stands for GNU Privacy Guard and it implements the OpenPGP standard which allows you to sign and encrypt messages and files. This is useful for a number of purposes. In our case it is important that you can sign files with your key, so they can be identified as something that you worked on. If you upload a source package to Launchpad, it will only accept the package if it can absolutely determine who uploaded the package.
To generate a new GPG key, run:
$ gpg --gen-key
GPG will first ask you which kind of key you want to generate. Choosing the default (RSA and DSA) is fine. Next it will ask you about the keysize. The default (currently 2048) is fine, but 4096 is more secure. Afterward, it will ask you if you want it to expire the key at some stage. It is safe to say “0”, which means the key will never expire. The last questions will be about your name and email address. Just pick the ones you are going to use for Ubuntu development here, you can add additional email addresses later on. Adding a comment is not necessary. Then you will have to set a passphrase. Choose a safe one. Now GPG will create a key for you, which can take a little bit of time; it needs random bytes, so if you give the system some work to do it will be just fine. Move the cursor around!
Once this is done, you will get a message similar to this one:
pub 4096R/43CDE61D 2010-12-06 Key fingerprint = 5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D uid Daniel Holbach <email@example.com> sub 4096R/51FBE68C 2010-12-06
In this case 43CDE61D is the key ID.
To upload (the public part of) of your key to a keyserver, so the world can identify messages and files as yours, just run:
$ gpg --send-keys <KEY ID>
There is a network of keyservers that will automatically sync the key between themselves.
SSH is a network protocol that allows you to exchange data in a secure way over the network. In a lot of cases you will use it to access and open a shell on another machine. It is also very useful to transfer files in a secure way.
To generate a SSH key, run:
$ ssh-keygen -t rsa
The default file name usually makes sense, so you can just leave it as it is. For security purposes, it’s highly recommended that you use a passphrase.
We will use the SSH key to securely push code changes to Launchpad.
pbuilder allows you to build packages locally on your machine. It serves a couple of purposes:
Setting pbuilder up is very easy. Edit ~/.pbuilderrc and add the following line to it:
COMPONENTS="main universe multiverse restricted"
This will ensure that build dependencies are satisfied using all components.
$ pbuilder-dist <release> create
where <release> is for example natty, maverick, lucid or in the case of Debian maybe sid. This will take a while as it will download all the necessary packages for a “minimal installation”. These will be cached though.
There are a few things you’ll need to set up in your development environment before you can start working on packages.
Launchpad is the central piece of infrastructure we use in Ubuntu. It stores not only our packages and our code, but also things like translations, bug reports, information about the people who work on Ubuntu and which teams they are part of. You’ll also use Launchpad to publish your proposed fixes, and get other Ubuntu developers to review and sponsor them.
You will need to register with Launchpad and provide a minimal amount of information, so that you can download and upload code, submit bug reports, and more.
If you don’t already have a Launchpad account, you can easily create one. If you have a Launchpad account but cannot remember your Launchpad id, you can find this out by going to https://launchpad.net/people/+me and looking for the part after the ~ in the URL.
Launchpad’s registration process will ask you to choose a display name. It’s encouraged for you to use your real name here. so that your Ubuntu developer colleagues will be able to get to know you better.
When you register a new account, Launchpad will send you an email with a link you need to open in your browser, in order to verify your email address. If you don’t receive it, check in your spam folder.
https://help.launchpad.net/YourAccount/NewAccount has more information about the process and additional settings you can change.
To find about your GPG fingerprint, run:
$ gpg --fingerprint <firstname.lastname@example.org>
and it will print out something like:
pub 4096R/43CDE61D 2010-12-06 Key fingerprint = 5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D uid Daniel Holbach <email@example.com> sub 4096R/51FBE68C 2010-12-06
Head to https://launchpad.net/people/+me/+editpgpkeys and copy the part about your “Key fingerprint” into the text box. In the case above this would be 5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D. Now click on “Import Key”.
Launchpad will use the fingerprint to check the Ubuntu key server for your key and, if successful, send you an encrypted email asking you to confirm the key import. Check your email account and read the email that Launchpad sent you. If your email client supports OpenPGP encryption, it will prompt you for the password you chose for the key when GPG generated it. Enter the password, then click the link to confirm that the key is yours.
Launchpad encrypts the email, using your public key, so that it can be sure that the key is yours. If your email software does not support OpenPGP encryption, copy the encrypted email’s contents, type gpg in your terminal, then paste the email contents into your terminal window.
Back on the Launchpad website, use the Confirm button and Launchpad will complete the import of your OpenPGP key.
Find more information at https://help.launchpad.net/YourAccount/ImportingYourPGPKey
Open https://launchpad.net/people/+me/+editsshkeys in a web browser, also open ~/.ssh/id_rsa.pub in a text editor. It is the public part of your SSH key, so it is safe to share it with Launchpad. Copy the contents of the file and paste them into the text box on the web page that says “Add an SSH key”. Now click “Import Public Key”.
More information is available at https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
Bazaar is the tool we use to store code changes in a logical way, to exchange proposed changes and merge them, even if development is done concurrently.
To tell Bazaar who you are, simply run:
$ bzr whoami "Bob Dobbs <firstname.lastname@example.org>" $ bzr launchpad-login subgenius
whoami will tell Bazaar which name and email address it should use for your commit messages. With launchpad-login you set your Launchpad ID. This way code that you publish in Launchpad will be associated with you.
Note: If you can not remember the ID, go to https://launchpad.net/people/+me and see where it redirects you. The part after the “~” in the URL is your Launchpad ID.)
Similar to Bazaar, the Debian/Ubuntu packaging tools need to learn about you as well. Simply open your ~/.bashrc in a text editor and add something like this to the bottom of it:
$ export DEBFULLNAME="Bob Dobbs" $ export DEBEMAIL="email@example.com"
Now save the file and either restart your terminal or run:
$ source ~/.bashrc
(If you use a different than the default shell, which is bash, please edit the configuration file for that shell accordingly.)
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 firstname.lastname@example.org 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.Read more
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 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:
Rock on everybody! You are all doing a stunning job!Read more
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:
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.Read more
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:
As I said above: today is the last day and it’s action-packed. Let’s see what’s going on today:
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:
Today is day 4, let’s see what it has in store for us today.
Excellent line-up, I’d say: let’s get cracking!Read more
© 2010 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.