Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.


This spec details a high-level view of a bleeding-edge Ubuntu release focusing on rapid deployment of updated software, here called "bleeding-edge."

Release Note

The bleeding-edge version of Ubuntu acts largely as its own testbed and quality assurance, or lack thereof; it does not track the stable or development branches of Ubuntu, and software only follows a short test period for interoperability. Canonical recommends the latest stable release of Ubuntu for production use.


A bleeding-edge version of Ubuntu could escape some of the quality assurance constraints of stable Ubuntu versions, allowing users to run the latest versions of software between releases without resorting to tracking development. Ubuntu could make versions of software newer than in the development branch available to users in this way; while users could still avoid running beta versions of GNOME or

Use Cases

Use cases fall to any user who does not wish to run a development branch, but will risk occasional breakage to always have the newest version of a software available.



A bleeding-edge version of Ubuntu should follow several design constraints.

  • The bleeding-edge distribution has, itself, a "stable," "testing," and "pretesting" branch.
    • stable includes packages admitted into bleeding-edge.

    • testing includes packages not thought (by intentionally arbitrary process) to lead to disruption. This includes minor updates to anything (i.e. 2.0.1 to 2.0.2). Testing packages must remain in testing for a short time period.

    • pretesting includes packages thought to lead to possible disruption. This includes major updates actually intended for "stable" without re-packaging, such as kernels, new critical infrastructure (HAL, dbus, udev), or major version updates (i.e. Pidgin 2.2 to 2.4). "pretesting" packages must remain for a longer time period before moving to "testing" for final evaluation.

  • The possibility of an "alpha" repository exists; but this would lead to management issues. GNOME alpha versions exist in development, running bleeding-edge "alpha" for this becomes pointless. A good balance may lie in running stable packages except for kernel (-rt, -mm, -git, -rc) and specific application (Firefox 3,, etc) packages, but this again becomes arbitrary and might fall to a popularity contest.


  • Implement bleeding-edge to track Ubuntu releases
    • Current released version of GNOME, KDE, and XFCE
    • Does not track release; when all of the core desktop of Ubuntu development goes stable, sync immediately to bleeding-edge "testing"

  • Create repositories
    • stable

      • Initially sync to Ubuntu stable; never sync again
    • testing

      • Populate with latest stable releases of software
      • Use a testing period of 1 week
      • When a package needs adjustment due to bad user experience, reset its test period back to 1 week
      • When a package causes a bad user experience with no resolution for 1 week, move it to "pretesting"
    • pretesting

      • Populate with latest kernels and matching support software (udev)
      • Use a pretesting period of 3 weeeks
      • Promote pretested software to "testing"
      • When a package needs adjustment due to bad user experience, round its pretesting period up to the next week (i.e. 9 days left, round to 14)
      • When a package gets minor bug fixes or updates, but does not cause reported bad user experiences, do not increase its pretesting period

Test/Demo Plan

Outstanding Issues

BoF agenda and discussion


BleedingEdgeUbuntu (last edited 2008-08-06 16:16:57 by localhost)