Ubuntu Wiki

Application Guidelines

This document comes with guidelines used to evaluate the 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.
• For cases where setting up an individual project in launchpad isn't feasible, the catch-all project "ubuntu-third-party-bugs" can be used.
• In order to assure that packages in third party repositories are being properly maintained, we require that the primary landing page that offers an apturl link must also contain a prominent link for reporting bugs in the used launchpad project.

Use-Case Prerequisites

• Only packages that fulfill a valid end user use cases will be considered.
• Only use-cases that cannot be served by software in the main ubuntu repository are considered valid.
• 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 record of robust usage.
• All applications will undergo a review by the Ubuntu third party application team. In case of 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 should start with a unique prefix and not conflict
  • with any existing name on the system
• File system layout of the package should be to install to /opt - unless there is a good reason for individual files to be shipped elsewhere.
• 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)

• Identify the maintenance type of the package: available options are "LTS" and "standard" (6-month-cycle)

  • add XB(S)-ThirdParty-Maintenance to the package; use "lts" for LTS packages and "standard" otherwise; the default is "standard"

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

Whitelist removal and blacklisting

Users have a right to expect high quality ongoing support and a robust user experience over time. Therefore, repositories may have to be removed.

Repositories might be removed for the following reasons:

• Packages of maintenance type "lts" have not been updated by the time the next LTS beta is released
• Packages of maintenance type "standard" have not been updated by the time the next beta is released
• Packages fail a quality review
• A breach of this policy

Depending on the problem a warning might be sent to the driver of the package. For serious problem or violations, the repository may be removed without warning. The repository will be removed by updating the white list following the normal update process, though with the repository removed from the list, rather than added. Note that this will only remove apt-url support for new users. It will not remove the repositories from the users' sources lists.

However, if necessary, the repository may actually be removed from the users' sources lists. This may be necessary if there are severe problems on the repository such as data loss errors, security problems, repository maintainer is not cooperating. The repository can not reapply for at least 1 year for inclusion again

Repositories in this manner will be removed in this manner by:

1. a security update is issued for app-install-data-partner that removes the repository from the package
2. the sources.list from the users system is inspected for the blacklisted repository and if its still in the users sources.list it is removed and a notification (via update-notifier hooks) is generated that tells the user about it.

~ubuntu-tpr determines necessary removal actions.