Ubuntu Wiki

Application Guidelines

Prerequisites

Formal:

• launchpad project (for each source package?)
  • Rational: transparency; monitoring the quality/repository state
• prominent link for reporting bugs in launchpad project on all landing (apurl
  • link) websites
  • Rational: Transparency for the team conducting regular quality reviews

• submitted application form based on ThirdPartyWhitelistApplicationTemplate

  • Rational: minimize load on approval process as all information required
    • before the approval gets submitted up-front

Use-Case:

• covers important enduser use-case for which a ThirdParty Repository is essential.

  • Rational: prevent archive proliferation; keep load on approval process justified
• no suitable alternative exists or can be maintained in the official ubuntu repositories
  • Rational: prevent archive proliferation

( Old: What packages: + proprietary

• + popular + overall beneficial for the ubuntu project, e.g. no equivalant free software available

+ free software

• + spirit of the package is too heavy wait for

  + too high regression risk for backports, e.g. wine needs frequent updates to enable new windows software, but risks regression that makes it unsuitable for backports => needs to be formulated positively

)

Repositoriy Quality Requirements

• repositories for stable ubuntu releases _must_ deliver a stable user-experience
  • comparable to those of ubuntu standards; the application must elaborate on the procedures used by the archive maintainer on how this is achieved; the decision is done by experienced members of 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. - Rational: Quality
  • we strongly recommend a similar process like the ubuntu SRU process ro ensure a good user experience. 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)
• 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

• + application submission + application review (~ubuntu-tpr) + package approval + whitelist rollout + regular quality reviews + whitelist removal; blacklisting

application submission

• third party repository driver files application as a bug against
  • app-install-data package

  • use ThirdPartyWhitelistApplicationTemplate

• subscribe ~ubuntu-tpr team and set bug to "Confirmed"

application review

• ~ubuntu-tpr team member to review formal prerequisites
  • if application does not meet formal prerequisites ~ubuntu-tpr team member
    • will ask for info and set to Incomplete; go back to application submission.
• ~ubuntu-tpr team member to review formal prerequisites
  • if application does not meet Use-Case prerequisites, the bug is marked as
    • invalid. Team member states reasons for rejection.

package review

• ~ubuntu-tpr drives the package reviewing process
• review Package Requirements (see above)
• optionally subscribe to ~ubuntu-archive in case a general package review or
  • second opinion is wanted
• set state to fix committed when ready

whitelist rollout (development release)

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

=== whitelist rollout (stable ubuntu releases)

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

regular quality reviews

• regular checks of the buglist
• regular review of repository contents (any new packages added without
  • approval?)
• 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

(

• team administrators are added/removed by technical board;
• team administrators (as well as team members) should send pre-notice before
  • stepping down from his role, so the technical board can appoint a successor.

)

== rest ... unsorted content ==

• launchpad project page for the repository is added
  • + so that bugs can be filed against the repo + to have general information for the third party repo
• update app-install-data-partner to include the new repository
  • (sources.list entry, gpg signing key)

regular quality reviews

• regular checks of the buglist
• regular review of repository contents (any new packages added without approval?)
• all repos part of the regular uprade testing
• on upgrade bugs from third-party report add apport mechanism to make them easy to find