[RFC] apturl repository whitelist application process

Alexander Sack asac at ubuntu.com
Thu Feb 12 10:24:49 GMT 2009

Hi all,

One of the topics on the jaunty agenda was to come up with a process
document that defines how third party repositories can apply for
apturl whitelisting and how we can ensure that such repositories are
of high maintenance quality. Based on various discussions we drafted an
initial policy-like draft, which you can find below. Please comment.

== 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

=== 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.

 * All applications must describe the procedures used by the archive
 maintainer on how this level of quality will be achieved and
 * Applications should be able to demonstrate a track recode of robust
 * 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 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
 * There must be no conflicting binary nor so names
 * Identify third party repository by custom package/source control
  * 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
  * add XB(S)-ThirdParty-BugFileUrl to the package that points to the
  bug report page (LP) 

== Application Process ==

=== High Level Workflow ===
 1. Application submission
 1. Application review (~ubuntu-tpr)
 1. Package review
 1. Whitelist rollout
 1. Regular quality reviews
 1. 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
 1. Subscribing the ~ubuntu-tpr team to the bug
 1. 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
 1. 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.
 1. If application does not meet Use-Case prerequisites, the bug is
 marked as
    invalid. Team member states reasons for rejection. The third party

=== package review ===
Upon accepting an application, ~ubuntu-tpr will follow the package
review process by:
 1. Reviewing Package Requirements (see above)
 1. optionally subscribe to ~ubuntu-archive in case a general package
 review or
   second opinion is wanted
 1. If accepted, the reviewer will set the state to fix committed when
 1. 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
 1. ~ubuntu-tpr team targets bug for suitable ubuntu releases
 1. ~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

=== 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
  * 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

Repositories my be removed for the following reasons::
 * The packages have not been updated for the upcoming release by beta
 * 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 lose 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
 1. 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.

[1] - https://wiki.ubuntu.com/ThirdPartyRepositoryApplicationProcess

 - Alexander Sack and Michael Vogt

More information about the ubuntu-devel mailing list