Extras repository process definition

m (Protected "Extras repository process definition" [edit=autoconfirmed:move=autoconfirmed])
 
(16 intermediate revisions not shown)
Line 2: Line 2:
== Analysis of current situation ==
== 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 wealth of our product, but me must guaranty
+
=== Nokia ===
 +
* There are many applications that would increase the value of our product(s), but we must guarantee:
** Quality (Quality)
** Quality (Quality)
** Ease of use (Simplicity)
** 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)
+
* 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)
-
* Nokia: We must keep security in mind - nobody must be able to inject bad packages etc... (Security, Control)
+
* 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)
+
* 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)
+
=== Developers ===
-
** judge, if the application has "quality" (Quality)
+
* We have problems promoting their software. (Promote)
-
* Developer: Developers have problems to promote their software   (Promote)
+
* It is difficult to assure that the application is installing and running well on all devices. (Quality Assurance)
-
* Developer: 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)
-
* Developer: There are multiple platforms and I need to do building for them all manually (Build management).
+
* We have problems to coordinating our work with the work of other developers—especially if using common libraries. (Coordination)
-
* Developer: I have problems to coordinate my work with work of other developers - especially if using common libraries (coordination).
+
* Not every developer is alike. The process must support:
-
* Developer: Not every developer is similar. The process must support
+
** Garage projects
-
** Garage
+
** External projects with local packaging
-
** External projects but local packaging
+
** External projects (Flexible)
** 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 ==
== Resulting Claims ==
Line 25: Line 31:
We need a process that...
We need a process that...
-
* Defines Quality
+
* '''Defines Quality''': What constitutes quality? A checklist for determining if a package is satisfactory.
-
* Assures Quality
+
* '''Assures Quality''': Each package undergoes QA to make sure it is satisfactory.
-
* Is simple
+
* '''Is simple''': Avoid unnecessary esoteric complications. Keep the process straightforward and well-documented.
-
* Is somewhat centric
+
* '''Is somewhat centralized''': The system is centralized for better control and better QA.
-
* Is scalable
+
* '''Is scalable''': The system will scale easily and cleanly under increased load.
-
* Assures security and control over the process
+
* '''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
+
* '''Is iterative for developers''': Development can take place in small steps.
-
* Helps user finding a application
+
* '''Eases building packages''': Reduces developer workload
-
* Helps promoting software
+
* '''Helps user finding applications''': Clear, clean, centralized organization helps users to find the software they need.
-
* Eases building packages
+
* '''Helps promoting software''': Help advertise and promote good software to users and the community.
-
* Must be flexible regarding package sources
+
* '''Must be flexible regarding package sources''': Flexible build and distribution system for a variety of package sources.
== Concepts ==
== Concepts ==
-
* We need a very clear definition of quality together with possible exceptions.
+
* 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.
+
* 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.
+
* 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 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.
* 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.
+
* 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 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.
* 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:
* While the process itself should be as much automated as possible we still need a team that decides in situations like:
** MIA
** MIA
-
** Packaging conflicts (multiple packages for the same software, different required versions) - especially for shared libraries and base packages.
+
** Packaging conflicts (multiple packages for the same software, different required versions)—especially for shared libraries and base packages.
== Solution strategies ==
== Solution strategies ==
Line 55: Line 61:
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.
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 ===
+
=== Bugzilla ===
* Each extras package should have its own defined bug tracking system (either in garage or a component in bugs.maemo.org?).
* 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.
* Try to synchronize application bug tracking system with upstream bug tracking system.
-
=== downloads.maemo.org ===
+
=== Downloads ===
-
* Add statistical information from the bug tracking system
+
* Add statistical information from the bug tracking system.
* [http://bugs.maemo.org/show_bug.cgi?id=2179 Bug 2179 - Visualize rating creation date and related software version].
* [http://bugs.maemo.org/show_bug.cgi?id=2179 Bug 2179 - Visualize rating creation date and related software version].
-
* Directly display available version in the extras repository '''- [http://lists.maemo.org/pipermail/maemo-developers/2008-July/034212.html Added 2008-07-07]'''
+
* Directly display available version in the Extras repository '''- [http://lists.maemo.org/pipermail/maemo-developers/2008-July/034212.html maemo.org/downloads automatic updates from Extras]'''
* Directly link to bug tracking "new bug" package for this application.
* Directly link to bug tracking "new bug" package for this application.
=== Device ===
=== Device ===
* [http://bugs.maemo.org/show_bug.cgi?id=1563 Bug 1563 - Application installer to send feedback to the providing site if install fails]
* [http://bugs.maemo.org/show_bug.cgi?id=1563 Bug 1563 - Application installer to send feedback to the providing site if install fails]
-
* Desktop should open crash report dialog if application crashes
+
* Desktop should open crash report dialog if application crashes.
* Application Manager should integrate rating of applications (possibly 3rd party application first).
* Application Manager should integrate rating of applications (possibly 3rd party application first).
=== Repository ===
=== Repository ===
-
* Nokia has initiated created of a extras-devel repository
+
* Nokia has initiated creation of an extras-devel repository.
-
* Initiate some variant of the debian staging process
+
* Initiate some variant of the debian staging process.
=== autobuilder ===
=== autobuilder ===
Line 84: Line 95:
* Needs to be a source package.
* Needs to be a source package.
-
* Needs to have a garage page or at least links to maintainer, upstream and a bug tracking system.
+
* Needs to have a Garage page or at least links to maintainer, upstream and a bug tracking system.
Process requirements:
Process requirements:
Line 104: Line 115:
* Possibly use [http://lintian.debian.org/ Lintian] as part of such solution ([https://bugs.maemo.org/show_bug.cgi?id=2240 Bug 2240 - Add Lintian])
* Possibly use [http://lintian.debian.org/ Lintian] as part of such solution ([https://bugs.maemo.org/show_bug.cgi?id=2240 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).
+
* Regularly install everything in the archive in a clean environment to check if there are installation installation conflicts (multiple packages installing same files).
=== autostager ===
=== autostager ===
Line 110: Line 121:
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.
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.
+
* Automatically create a page on Downloads if it does not exist.
=== Package ===
=== Package ===
* [http://www.hadrons.org/~guillem/debian/docs/origin.proposal Origin field in deb]
* [http://www.hadrons.org/~guillem/debian/docs/origin.proposal Origin field in deb]
 +
 +
=== Quality Assurance ===
 +
 +
Your ideas here.
 +
 +
* Visibility and promotion of [http://maemo.org/maemo_release_documentation/maemo4.1.x/node16.html 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.--[[User:qgil|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.--[[User:qgil|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.--[[User:qgil|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 [http://wiki.debian.org/piuparts piuparts] would help find issues with installing, upgrading, downgrading, and removing packages.
== Links ==
== Links ==

Latest revision as of 14:10, 14 June 2012

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