UbuntuDevelopment

Differences between revisions 44 and 45
⇤ ← Revision 44 as of 2007-01-29 15:13:18 →
Size: 15120
Editor: 82-69-40-219
Comment: anchor for Consistency
← Revision 45 as of 2007-01-29 16:03:44 → ⇥
Size: 15121
Editor: 217
Comment: fix links
Deletions are marked like this. Additions are marked like this.
Line 65: Line 65:
Bazaar, an open source revision control system and Canonical sponsored project, is the preferred revision control system in Ubuntu. Many Ubuntu packages are [BzrMaintainerHowto maintained in Bazaar], which makes it easy for other developers to [BzrContributorHowto contribute changes to them], which can be easily merged by the maintainer. Bazaar, an open source revision control system and Canonical sponsored project, is the preferred revision control system in Ubuntu. Many Ubuntu packages are [:BzrMaintainerHowto:maintained in Bazaar], which makes it easy for other developers to [BzrContributorHowto:contribute changes to them], which can be easily merged by the maintainer.

Overview of Development

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

Working with Other Developers

You are not alone! Ubuntu is the work of many developers, and we devote some effort to enabling efficient collaboration with tools, infrastructure, government and a cooperative spirit.

Starting points

The [:MOTU] team, in addition to their development activities, provide information and guidance for new and prospective Ubuntu developers. If you're newly interested in Ubuntu development and looking for answers, introduce yourself and listen in!

If you already have experience working with Debian packages, most of your knowledge applies equally well to Ubuntu packaging. If you are a Debian developer, UbuntuForDebianDevelopers summarizes some of the differences between the projects, and later sections in this document provide details of our infrastructure.

XXX - bite-sized projects go here -mdz

Communication

Email discussion among Ubuntu developers takes place on the [http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel ubuntu-devel mailing list], which is moderated (excepting registered 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. [https://lists.ubuntu.com/mailman/listinfo/ Various other mailing lists] are available, some of which focus on specific areas of development.

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

[#Notifications Automated notifications of development activity] are also useful for keeping up with what other developers are working on.

Bugs

[http://bugs.launchpad.net/ubuntu Ubuntu bug reports] are tracked in Launchpad. HelpingWithBugs contains information about how they are handled. The BugSquad documentation describes how to cooperate with other developers and volunteers working on bug triage; it is required reading for new developers, as developers will typically need to spend a significant amount of time working with the [https://launchpad.net/ubuntu/+bugs bug tracking system].

Packaging

If you're interested in packaging work, but don't have much experience yet, 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.

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 a mailing list first

Anchor(Bazaar)

Revision control (Bazaar)

Bazaar, an open source revision control system and Canonical sponsored project, is the preferred revision control system in Ubuntu. Many Ubuntu packages are [:BzrMaintainerHowto:maintained in Bazaar], which makes it easy for other developers to [BzrContributorHowto:contribute changes to them], which can be easily merged by the maintainer.

Derivative Distributions

Several derivatives of Ubuntu are available (also sometimes called "flavours"). A number of people in the Ubuntu community work on one or more of these derivative versions. Kubuntu, Edubuntu, and Xubuntu are all maintained directly in the Ubuntu archive.

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.

The Package Archive

All current official Ubuntu packages are stored in the master archive, which is widely [:Mirrors:mirrored]. A search interface is available at [http://packages.ubuntu.com]. Old versions can be retrieved from [http://launchpad.net/ubuntu Launchpad].

It is administered by the [http://launchpad.net/~ubuntu-archive archive administration team].

Anchor(Uploading)

Uploading

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

Packages are uploaded via FTP to ftp://upload.ubuntu.com/ using dput or dupload.

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)

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.

To add a new package to Ubuntu, simply upload it as usual. Any new packages uploaded are put in a [https://launchpad.net/ubuntu/feisty/+queue queue] to be checked by the administrators before being included.

Autobuilding and Publishing

Once an upload has been accepted, it takes some time to be [#Autobuilders built] and published in the archive. For simple packages, this is usually on the order of an hour, but varies depending on release activity (uploads may be temporarily suspended), the time needed to build the package (including other packages in the build queue), and other factors.

Anchor(Notification)

Notification of changes

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

RSS Feeds of these messages are available at [http://www.ubuntulinux.nl/files/].

Changelogs for all packages are available at http://changelogs.ubuntu.com/changelogs/ (this is the source used by update-manager and Synaptic).

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. Packages which are [#Bazaar maintained in Bazaar] can be merged using Bazaar itself.

Backports work similarly to syncs, but have somewhat different requirements. To request a backport, follow the BackportRequestProcess.

Anchor(Consistency)

Consistency

The archive is periodically checked for various inconsistencies, such as incorrect dependency relationships between packages.

Managing Components

Ubuntu packages are classified into components according to [http://www.ubuntu.com/ubuntu/components maintenance and licensing criteria], a process which is described in SeedManagement.

Packages sometimes move from one component to another, according to policy or licensing changes, as managed by the archive administrators. Special consideration is necessary when packages move into main or restricted, as this implies a commitment of ongoing maintenance. Such changes must follow the MainInclusionProcess.

Autobuilders

Ubuntu source packages are automatically built for a variety of platforms by Launchpad, which provides [https://launchpad.net/ubuntu/+builds build status information]. Build log files are available from Launchpad as well, by [https://launchpad.net/ubuntu/ searching for the package] and selecting a version.

Some supplementary information about the build infrastructure is available on BuildDaemons.

CD Images

An automated system builds CD and DVD images based on the packages in the archive. Its log files are available from [http://people.ubuntu.com/~cjwatson/cd-build-logs/], and the set of packages included on them is driven by the [:SeedManagement:seeds].

New builds are usually produced on a daily basis and published at [http://cdimage.ubuntu.com/ cdimage.ubuntu.com]. Officially released images are published at [http://releases.ubuntu.com/ releases.ubuntu.com]. Both are available via HTTP, [:RsyncCdImage:rsync] and BitTorrent.

Removing Packages

Packages which are removed from Debian are semi-automatically removed from Ubuntu universe on a regular basis by the administrators. However, packages are not removed from Ubuntu main without explicit request, nor are packages which originated elsewhere. To request removal of such a package, file a bug against the package and subscribe the ubuntu-archive team. If you need help deciding whether a package ought to be removed, please discuss on the ubuntu-devel mailing list rather than asking the archive administrators.

Anchor(ReleaseProcess)

The Release Process

Features and Schedule

XXX - specifications, developer summits

Milestones

XXX - purpose and definition

Anchor(Freezes)

Freezes

XXX - purpose and definition

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.

Other Resources

These resources should be incorporated into new or existing sections elsewhere in this document, but are temporarily recorded here so that we remember to come back to them later:

UbuntuDevelopment (last edited 2023-02-09 00:47:28 by arraybolt3)