Ubuntu Wiki

THIS IS A WORK IN PROGRESS. I hope to incorporate and supersede DeveloperResources.

Overview of Development

Ubuntu is developed by a [http://launchpad.net/~ubuntu-dev team of developers], including both [http://launchpad.net/~ubuntu-core-dev core developers] and ["MOTU"]. It is based on [http://www.debian.org/ Debian], and [wiki:TimeBasedReleases periodically released] according to a [wiki:ReleaseScheduleTemplate schedule].

Working with Other Developers

You are not alone! The development of Ubuntu is a collaborative effort.

Email discussion among Ubuntu developers takes place on the [http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel ubuntu-devel mailing list] (posting will be moderated, excepting official Ubuntu developers). The [http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss ubuntu-devel-discuss mailing list] is available for open discussion about Ubuntu development.

Similarly, the #ubuntu-devel channel on the FreeNode IRC network is home to many Ubuntu developers.

Packaging and Uploading

If you're interested in packaging work, you should get in touch with [:MOTU:the MOTU team], who provide mentoring for new developers.

XXX: fix overlap with ["MOTU/Documentation"].

Working with Debian-format Packages

Ubuntu uses the Debian packaging format. The following resources explain how to create and modify Debian-format packages.

• If you are already familiar with Debian development, UbuntuForDebianDevelopers explains some of the differences between the projects.

• All Ubuntu developers should be familiar with the [http://www.debian.org/doc/maint-guide/ Debian New Maintainer Guide], though be aware that there are many differences (technical, social and procedural) between Ubuntu and Debian of which they must also be aware.

• [http://women.alioth.debian.org/wiki/English/PackagingTutorial A packaging tutorial] is available from the Debian Women project, as is [http://women.alioth.debian.org/wiki/English/MaintainerScripts an explanation of MaintainerScripts]

• Many packages use tools to help manage multiple patches. [https://wiki.ubuntu.com/MOTU/School/PatchingSources Patching Ubuntu packages] (from the MOTU school) explains how to work with them.

  • The [https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml CDBS Manual] explains how to work with packages using the CDBS packaging scripts, one example of a patch system (and more)

• For a deeper understanding of the packaging process, you might want to have a look at this one: http://women.alioth.debian.org/wiki/English/BuildingWithoutHelper

• http://people.debian.org/~calvin/unofficial/ contains information on maintaining your own archive of unofficial packages.

• Tamir wrote an article on [http://ubuntuforums.org/showthread.php?t=51003&page=1&pp=10 How to make Debian-standard debs from scratch] on the Ubuntu Forums

• [https://lists.ubuntu.com/archives/ubuntu-motu/2006-February/000443.html how to write watch files] for sourceforge.net hosted projects

Working with Ubuntu Packages

• Set the target suite in debian/changelog to be the code name of the current development branch, e.g. "dch -D feisty"

• When working with a package which originated in Debian, use a version number derived from the Debian version number with ubuntu<revision> appended. e.g. Debian 1.0-2 becomes 1.0-2ubuntu1, followed by 1.0-2ubuntu2, etc.

• Packages not in debian yet should end with revision -0ubuntu1 (To Be Discussed: see [https://launchpad.net/ubuntu/+spec/package-version-conflicts] )

• Remember to include the orig.tar.gz if this is a new upstream version of a non-native package but you have already patched it before upload. A missing original tarball may cause a silent drop depending on the archive scripts. Use dpkg-buildpackage -S -sa to generate such an upload. If the orig.tar.gz is already in the distribution then you don't need to upload it again.

• Always be aware of the release schedule and any applicable [#Freezes freezes]. The cooperation of all developers is needed in order to ensure a successful release!
• If your changes may affect the work of other developers, it is a good idea to discuss them on the

Building

You should always build and test packages locally before submitting them to Ubuntu. Failure to do so will waste the time of other members of the community, so please be considerate.

• You may want to build them in a [:DebootstrapChroot] or in [:PbuilderHowto:pbuilder]

• Backports are explained at [:BackportsHowto]

Anchor(Uploading)

Uploading

If you are not yet an official Ubuntu developer, you can arrange for your package to be uploaded via the SponsorshipProcess.

Notes for preparing your upload:

• Make source-only uploads, i.e. use "dpkg-buildpackage -S"

• When uploading to [:REVU], please include the orig tarball as well (use parameters -S -sa)

Packages are uploaded via FTP to ftp://upload.ubuntu.com/

Example dput.cf entry:

      ![ubuntu]
      fqdn = upload.ubuntu.com
      incoming = /
      login = anonymous

Example dupload.conf entry:

       $cfg{'ubuntu'} = {
           fqdn => "upload.ubuntu.com",
           incoming => "/",
           dinstall_runs => 1,
       };

When your upload is processed (typically within a matter of minutes), you will receive an email with the result of your upload, whether it succeeds or fails, unless you use an unregistered email address. The system will only send mail to an address which belongs to a launchpad account which is a member of the relevant team for uploading. E.g. [http://launchpad.net/people/ubuntu-dev ubuntu-dev] for universe and [http://launchpad.net/people/ubuntu-core-dev ubuntu-core-dev] for main.

Your upload must be signed by GPG key registered in launchpad. If the signature cannot be traced to a member of the appropriate team, then the upload will be silently rejected.

Notifications of uploads are also sent to a mailing list. A different list is used for each Ubuntu release:

• [http://lists.ubuntu.com/mailman/listinfo/dapper-changes/ dapper]

• [http://lists.ubuntu.com/mailman/listinfo/edgy-changes/ edgy]

• [http://lists.ubuntu.com/mailman/listinfo/feisty-changes/ feisty]

Archive Administration

New Packages

Any new packages uploaded are put in a queue to be checked by the archive administrators before being included.

Autobuilders

Syncing and Merging

Most packages in Ubuntu originate elsewhere, including Debian and related package repositories.

A sync copies a source package verbatim from an external repository into Ubuntu, overwriting any package of the same name. This is used when a newer version of it is available, and should be included in Ubuntu, and happens automatically during some phases of the release cycle. To request a sync, follow the SyncRequestProcess.

A merge is a three-way merge of a package which originated in an external repository. This is used when there is a newer version available from the external repository, but the package has also been modified (branched) in Ubuntu. MergeoMatic is a tool to assist with this work, and ["MOTU/Merging"] explains how and when to merge.

The Release Process

Milestones

XXX - purpose and definition

Anchor(Freezes)

Freezes

XXX - purpose and definition

• Freeze states are described on the release schedule for the current release ([:FeistyReleaseSchedule:feisty]), and the ReleaseScheduleTemplate

• To request an exception, follow FreezeExceptionProcess

Stable Releases

Released versions of Ubuntu are intended to be stable. This means that users should be able to rely on their behaviour, and therefore, updates are only released under special circumstances. These criteria, and the procedure for preparing such an update, are described in StableReleaseUpdates and SecurityUpdateProcedures.