Extras repository process definition

To provide the simplest interface for end users to get good quality third party software that downloads and installs flawlessly, without compromising their default system. To provide maemo tools and infrastructure to developers so they can check the quality of their software, offer it to end users and promote it.

– Quim Gil

Contents

Analysis of current situation

Extras needs to satisfy the requirements and desires of a number of groups.

Nokia

  • There are many applications that would increase the wealth of our product, but we must guarantee:
    • Quality (Quality)
    • Ease of use (Simplicity)
  • We want to empower the community to push and promote the software they think is good enough for that. For this we think a centralized aproach makes sense and will make things easier", "simpler" and adds service—without compromising the open source ideal. (Simplicity, centric, scalability)
  • We must keep security in mind—nobody must be able to inject bad packages etc... (Security, Control)
  • We want to attract new developers and give them a guided testing bed. (Iterative)

Developers

  • We have problems promoting their software. (Promote)
  • It is difficult to assure that the application is installing and running well on all devices. (Quality assurance)
  • There are multiple platforms that we need to build manually for. (Build management)
  • We have problems to coordinating our work with the work of other developers—especially if using common libraries. (Coordination)
  • Not every developer is similar. The process must support:
    • Garage projects
    • External projects with local packaging
    • External projects (Flexible)

Users

  • There are a huge number of applications. Most of the applications would promote the devices and the platform, but it is difficult to:
    • Find applications (Locate)
    • Judge if the application is of good "quality" (Quality)

Resulting Claims

We need a process that...

  • Defines Quality: What constitutes quality? A checklist for determining if a package is satisfactory.
  • Assures Quality: Each package undergoes QA to make sure it is satisfactory.
  • Is simple: Avoid unnecessary esoteric complications. Keep the process straightforward and well-documented.
  • Is somewhat centralized: The system is centralized for better control and better QA.
  • Is scalable: The system will scale easily and cleanly under increased load.
  • Assures security and control over the process: Centralized system to control the quality of packages and help assure packages and the system are safe and secure.
  • Is iterative for developers: Development can take place in small steps.
  • Eases building packages: Reduces developer workload
  • Helps user finding applications: Clear, clean, centralized organization helps users to find the software they need.
  • Helps promoting software: Help advertise and promote good software to users and the community.
  • Must be flexible regarding package sources: Flexible build and distribution system for a variety of package sources.

Concepts

  • We need a very clear definition of quality (with possible exceptions to avoid excessively stringent qualifications).
  • Use Debian staging approach with multiple repositories (unstable, testing, stable). Tune it to fit for smaller number of packages and smaller community. This includes uploading of only source packages and an autobuilder.
  • Define a bug tracking system as master for all Extras packages.
  • Enhance the application catalog to give the user a hint about the measured quality of an application.
  • Enhance the application catalog to allow the user to rate the quality of an application.
  • Try to directly link (aka http links) and integrate (linking information) bug tracking system and application catalog.
  • Enhance the packaging format link to package specific information in the bug tracking system and in the application catalog.
  • Enhance the device to simplify the rating, quality assurance and bug tracking process.
  • While the process itself should be as much automated as possible we still need a team that decides in situations like:
    • MIA
    • Packaging conflicts (multiple packages for the same software, different required versions)—especially for shared libraries and base packages.

Solution strategies

The resulting solution strategy consists of a number of concrete proposals for changes and additions to the existing infrastructure to create an environment to fit the requirements.

Bugzilla

  • Each extras package should have its own defined bug tracking system (either in garage or a component in bugs.maemo.org?).
  • Try to synchronize application bug tracking system with upstream bug tracking system.

Downloads

Device

Repository

  • Nokia has initiated creation of an extras-devel repository.
  • Initiate some variant of the debian staging process.

autobuilder

The autobuilder automatically builds packages based on source packages.

Package requirements:

  • Needs to be a source package.
  • Needs to have a Garage page or at least links to maintainer, upstream and a bug tracking system.

Process requirements:

  • Simple (re)upload of packages
  • Automatically compile one package for multiple OSs (OS 2006, OS 2007, OS 2008)
  • Automatically recompile everything for a new OS.
  • Automatically update corresponding downloads.maemo.org page.
  • Should honor build dependencies (build dependencies first).
  • Always build in a clean environment that only has build dependencies preinstalled. Thus checking for missing build dependencies.
  • Possibility to manually force rebuild of a certain package or all dependencies of a certain package (e.g. an unversioned dependency changes).
  • Push packages only into the repository, if all runtime dependencies are fulfilled.
  • Automatically notify the package maintainer on build failures (per email or per bug tracking system).
  • Uploading to the autobuilder should be possibly directly from the garage project page.

autotester

The autotester does some automatic tests on build packages to assure certain packaging quality constraints.

  • Possibly use Lintian as part of such solution (Bug 2240 - Add Lintian)
  • Regularly install everything in the archive in a clean environment to check if there are installation installation conflicts (multiple packages installing same files).

autostager

The autostager does some automatic rating of a package base on a number of criteria and information source to judge its quality and thus add the package to a certain staging repository or to remove it from a staging repository.

  • Automatically create a page on Downloads if it does not exist.

Package

Quality Assurance

Your ideas here.

Links

Retrieved from "http://bugs.maemo.org/Extras_repository_process_definition"