This document will try to give some pointers how to contribute to Ubuntu Touch, how to find projects and the code for specific components, how to propose changes etc. Even though this guide is generally targeted for developers, some sections also overview possible contributions in other fields like translations and testing.

Development

General guidelines

First step when trying to help out with development is to find the component you would like to help in. Ubuntu Touch is made from many different parts - for instance, the rootfs of the current stable images is made off 1146 different Debian binary packages. This of course doesn't mean the knowledge of all of them is required to be able to develop - only a small subset is actually important from the touch perspective.

The basics

At first it's good to understand that Ubuntu Touch is very similar, in principle, to the regular desktop Ubuntu. The rootfs, so the main part of the device where all the core components are stores, is just another Ubuntu image governed by a seed (the ubuntu-touch seed). There is of course more than just the rootfs, but in this guide we'll concentrate on contributing to those components - see this guide for more information about the device and custom tarballs if you're interested.

The rootfs (the ubuntu tarball) is the Ubuntu part of the system that is booted and used. It carries all the packages and binaries for the graphical shell, the user session and basically everything that can communicate with the lower-level drivers. That's the most possible place for user-visible bugs and whenever one wants to do some enhancements.

List of most common components and their project links:

• Graphical interface

  • unity8 - This is the main project providing the user-visible shell.

  • mir - The display server.

  • qtmir -

  • qtubuntu -

• Telephony and networking
  • ...
• Core applications
  • ...

Most of the core components and a few core applications are provided in the form of Debian packages

Working on a fix

Almost all Ubuntu Touch specific core component code is hosted on Launchpad using bzr or git. Usually to get the project's code and packaging a simple bzr branch lp:projectname should work. For those that aren't hosted on Launchpad, you need to download the Debian source package and extract it.

Launchpad based projects

Almost all touch projects that are hosted on Launchpad use the Bileto tool for releasing. You can read about the Bileto Landing Process here, but generally landings can only be performed by privileged Landers. As a contributor you can prepare a fix and ask a Lander to release it for you into the archives and, then, our official touch images. We'll talk about this in a bit.

To start working on a fix, you first need to download the project code. As mentioned above, you can simply use bzr or git to fetch the main trunk to your local machine (check project page for details). For most projects the trunk branch is the place to start.

At any time when working on a fix, you can do test-builds of your changes by using the bzr builddeb command. Bileto-enabled projects come with self-contained Debian packaging, meaning that you can build a package out of the current code contents any time you want. Running bzr builddeb (after making sure all the build dependencies are installed) will build a binary package of the current code on your local machine. Please be aware that the generated binary package will be built for your architecture only (generally amd64) so the packages will not work on an Ubuntu Touch armhf device (see cross-building). What you can do though is create a Launchpad PPA and enable an armhf builder on it and using that for building your packages. Usually what you would do then is create a source package with bzr builddeb -S and upload it to your PPA through dput ppa:yourlpname/ppaname *.changes. It's useful to modify the debian/changelog file before pushing, to make sure the version number is different and recognizable (dch -i).

Once you're happy with your change and have tested it locally, it's time to prepare a merge request for it. Commit your changes (bzr commit), push to a remote location (bzr push lp:~yourlpname/projectname/branch_name, e.g. bzr push lp:~foo/unity8/fix_for_lp1234567), go to your remote branch on Launchpad and select Propose for Merging. Fill in all the details (Description, Commit Message etc.) and, best, link the selected branch to the bug the change is supposed to fix (if present). You are now ready to find the Lander for the given project and poke him with the Merge Proposal. Usually upstream maintainers automatically notice MP's by themselves, but it's always better to ask directly and provide additional context.

Source-package only projects

...

Others