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

The Extras repository needs to maintain a high level of quality applications.

Nokia

  • There are many applications that would increase the value of our product(s), 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 alike. 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?).
    • Ensuring that each package has its own bug-tracking system isn't feasible. What about trivial make/compile ports, and packages which are adapted from debian largely unchanged. These will appropriately have essentially no maemo-specific infrastructure, and will have infrastructure upstream instead. Also consider the case of a very immature project with a single developer who hasn't created infrastructure yet.
    • Instead, extras should have its own bug-tracker which applies to extras as a whole.
    • Each package should have an owner, who may or may not be the upstream developer. The owner must watch the extras bug-tracker for bugs submitted against their packages.
    • Bugs which are appropriately resolved upstream should be resubmitted there, either by the package owner, or by closing the bug wontfix with a comment that certain types of need to be dealt with upstream and a polite message requesting that the submitter resubmit the bug there.
    • Extras is essentially a linux distro. The above bug handling strategies are used by every major distro on the planet, we should use them too.
  • 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.

  • Visibility and promotion of Quality considerations for application developers.
    • A checkbox requesting the developer to say 'Yes, I'm aware of the quality considerations and I have done my best implementing them in my software"? Might sound a bit stupid and totally by-passable but it might be a good promotion of these quality considerations.--qgil 09:28, 21 November 2008 (UTC)
  • Perhaps a very basic and descriptive list of Very Basic Testing to do in each release?
  • Automated testing, what can be done on the server side?
  • Some days of quarantene in extras-testing when promoting a package from extras-devel, no matter what?
    • Hum, falling again in the unstable-testing-stable paradigm.--qgil 09:28, 21 November 2008 (UTC)
  • Objective criteria to demote a package from extras to testing/devel?
    • What would happen to regular users with that package installed? They might be confused if a human-readable notification doesn't tell them what's going on.--qgil 09:28, 21 November 2008 (UTC)
  • Nokia to include extras apps in their own testing.
  • Specific QA routines to be defined for extras apps being promoted in maemo.nokia.com or other marketing activities.
  • Automated use of Debian tools like piuparts would help find issues with installing, upgrading, downgrading, and removing packages.

Links

Retrieved from "https://wiki.maemo.org/Extras_repository_process_definition"