Ubuntu – How to start contributing to Ubuntu development

The getting involved page on unity.ubuntu.com has an initial set of instructions to get started.

It looks like you've already branched the code. You can just edit it with whatever editor you prefer (the unity folks don't have a specific IDE, it's just personal preference). After you've made the change you want you can do a bzr commit and then you need to build Unity to test it:

• How do I build Unity from source?

You don't have to follow the part of the instructions where you pull unity from Launchpad, you've already done that.

After you've fixed what you want you can submit the branch to Launchpad if you want the Unity folks to integrate it.

We have a page full of bitesize bugs for people who are just getting started if they want to tackle something small to get used to the codebase.

• IRC Logs from a tutorial session.
• How to contact the Unity team.

If you have specific questions about parts of the unity code just ask them as new questions and tag them with unity and Unity developers will look at them, it will be useful to start building up a bunch of questions and answers about the Unity codebase!

You need to conceptually separate Ubuntu from upstream, even when the upstream branch is hosted on Launchpad. The vast majority of packages in Ubuntu have their upstream branch hosted somewhere else completely (i.e. GitHub or SourceForge). An upstream project that is hosted on Launchpad might have a closer relationship with Ubuntu, but it should be treated essentially like any other upstream project.

Ubuntu redistributes upstream software usually only making changes when necessary for integrating with all the other software we ship. In most cases, the best option is to fix bugs upstream. That way the fix reach the most people. This also reduces the burden in Ubuntu by not having to maintain the local modifications.

So ideally, the process looks like your first option. You fix the bug upstream, upstream makes a new release, and Ubuntu updates to that version. As you've noticed, things don't always work that way.

Sometimes the release schedules of Ubuntu and an upstream project might not be aligned. Say you've found and fixed a bug that you'd like to see in the next Ubuntu release, but Ubuntu is releasing in three months and upstream has no idea when its next release will be. In a situation like this, the best approach is to fix the bug upstream but backport it to the release in Ubuntu as an Ubuntu specific patch. This is also the case when making a fix in a stable release of Ubuntu where we will most likely not be able to include a new upstream release.

Sometimes Ubuntu carries changes to upstream. If the bug lies in those changes, the fix should go directly to Ubuntu. This includes issues in things like the packaging.

New features are extremely unlikely to be accepted in Ubuntu unless it has already been accepted upstream. We will often accept patches fixing a specific problem before its been applied upstream for the sake of the larger project, but we normally don't like to deviate from upstream in terms of design or functionality.

I know that I'm basically just saying it depends, but it does!