Ubuntu Wiki

Application Guidelines

This policy governs inclusion of third party repositories that can automatically be added to a user's sources list via an apturl link. This will result in a user experience where certain third party packages can be installed by clicking on a hyperlink, and then can be automatically updated via the normal Ubuntu apt mechanisms.

Users benefit from having a small number of well maintained archives to manage. Therefore, packages should be placed in the appropriate official Ubuntu repository. This process is only for extreme exceptions where inclusion in a Ubuntu repository is not feasible due to licensing or technical issues.

Prerequisites

Before being considered for acceptance as a third party repository, the project must meet the following prerequisites.

Formal Prerequisites

• In order to ensure transparency and to facilitate monitoring of quality and the state of the repository, a launchpad project must be maintained for the package. Each source package should have it's own repository where appropriate.
• In order to assure that packages in third party repositories are being properly maintained, each landing page that offers an apturl link must also contain a prominent link for reporting bugs in the related launchpad project.

Use-Case Prerequisites

• Only packages that are essential for fulfilling very common end user use cases will be considered.
• Only packages where inclusion in the appropriate Ubuntu repository is not feasible for some technical or licensing reason will be considered.

Repository Quality Requirements

Users have a right to expect the same level of quality and stability from packages installed via apturl as applications installed from other methods. Therefore, third party repositories for stable Ubuntu release _must_ deliver a stable user-experience comparable to those of ubuntu standards.

Therefore:

• All applications must describe the procedures used by the archive maintainer on how this level of quality will be achieved and maintained.
• Applications should be able to demonstrate a track recode of robust usage.
• All applications will undergo a review by the Ubuntu third party application team. In case a rejection the team will provide a list of problems identified and suggestions on how those can be fixed.
• Accepted repositories will undergo process similar to the ubuntu SRU process to ensure. This includes reviews/testing in a staging area documented in bugs.

Package Requirements

• Package namespace for the name must start with a unique prefix and not conflict
  • with any existing name on the system
• File system layout of the package must be to install to /opt (ensure that desktop
  • files are still available)
• There must be no conflicting binary nor so names
• Identify third party repository by custom package/source control field

  • add XB(S)-ThirdParty-RepoURL to the package that is uniq to identify where the master repo is

• Identify right place to file bugs by custom package/source control field

  • add XB(S)-ThirdParty-BugFileUrl to the package that points to the bug report page (LP)

Application Process

High Level Workflow

1. Application submission
2. Application review (~ubuntu-tpr)
3. Package review
4. Whitelist rollout
5. Regular quality reviews
6. Whitelist removal and blacklisting

In general, the process will be guided by ~ubuntu-tpr, though they may ask other teams for reviews and support as needed.

Application Submission

To begin the process, the "driver" (owner) of the third party repository applies for consideration by:

1. Filing an application as a bug against app-install-data package using the ThirdPartyWhitelistApplicationTemplate

2. Subscribing the ~ubuntu-tpr team to the bug
3. Setting the bug to "Confirmed"

Application Review

Upon receiving an application a ~ubuntu-tpr team member will:

1. Review the application checking for adherence to the formal prerequisites.
2. If the application does not meet the formal prerequisites ~ubuntu-tpr team member will ask for info and set to Incomplete. The third party driver may then reapply, if desired.
3. If application does not meet Use-Case prerequisites, the bug is marked as
   • invalid. Team member states reasons for rejection. The third party driver

package review

Upon accepting an application, ~ubuntu-tpr will follow the package review process by:

1. Reviewing Package Requirements (see above)
2. optionally subscribe to ~ubuntu-archive in case a general package review or
   • second opinion is wanted
3. If accepted, the reviewer will set the state to fix committed when ready.
4. If not accepted the reviewer will marked the bug as incomplete and include the reason. Reason for not being accepted can include concrete technical bits, but also a request to prove a track record.

whitelist rollout (development release)

In order for the third party repository to work with apturl, it will need to be added to the white list,a nd the white list updated. If the repository is being added to a release under development, the whitelist will be rolled out as follows:

1. ~ubuntu-tpr team commits whitelist to app-install-data
2. ~ubuntu-tpr team targets bug for suitable ubuntu releases
3. ~ubuntu-tpr team to drive roll out of packages to current development release

whitelist rollout (stable ubuntu releases)

If the repository is being added to a current stable release, then the following process will be followed:

1. ~ubuntu-tpr team will regularly publish accumulated whitelist changes to
   • UBUNTU-proposed/updates

Regular quality reviews

At a predefined interval, ~ubuntu-tpr will do a quality review of each third party repository by:

• regular checks of the buglist to ensure that bugs are processed and addressed.
• regular review of repository contents to ensure that no new packages added without
  • approval.
• reviews will occur on an ongoing basis, but a good practice is to ensure a review after beta, with the RC as the final deadline for fixing bugs.

~ubuntu-tpr will also:

• ensure that all repos part of the regular uprade testing
• on upgrade bugs from third-party report add apport mechanism to make them
  • easy to find

~ubuntu-tpr team constitution

• team members are allowed to do any part of the approval process
• team members are added/removed by the team administrators