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

  • Nokia: There are many applications that would increase the wealth of our product, but me must guaranty
    • Quality (Quality)
    • Ease of use (Simplicity)
  • Nokia: 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 idea. (Simplicity, centric, scalability)
  • Nokia: We must keep security in mind - nobody must be able to inject bad packages etc... (Security, Control)
  • Nokia: We want to attract new developers and give them a guided testing bed (Iterative)
  • User: There are a huge number of applications. Most of the applications would promote the devices and the platform, but it is difficult to
    • find the application (Locate)
    • judge, if the application has "quality" (Quality)
  • Developer: Developers have problems to promote their software (Promote)
  • Developer: It is difficult to assure that the application is installing and running well on all devices (Quality assurance)
  • Developer: There are multiple platforms and I need to do building for them all manually (Build management).
  • Developer: I have problems to coordinate my work with work of other developers - especially if using common libraries (coordination).
  • Developer: Not every developer is similar. The process must support
    • Garage
    • External projects but local packaging
    • External projects (Flexible)

Resulting Claims

We need a process that...

  • Defines Quality
  • Assures Quality
  • Is simple
  • Is somewhat centric
  • Is scalable
  • Assures security and control over the process
  • Is iterative for developers
  • Helps user finding a application
  • Helps promoting software
  • Eases building packages
  • Must be flexible regarding package sources

Concepts

  • We need a very clear definition of quality together with possible exceptions.
  • 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.

bugs.maemo.org

  • 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.maemo.org

Device

Repository

  • Nokia has initiated created of a 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 their 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.maemo.org if it does not exist.

Package

Links

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