[maemo-developers] RFC: Proposal to solve multiple repository, poor QA situation

[From: Andrew Flegg]

Hi,

This morning[1] I think I came up with a solution to the problems that
have recently been discussed on maemo-users of too many repositories
and not enough QA on packages.

I'd like to raise it here for discussion to polish it, and then
volunteers to help implement it.


PROBLEMS
~~~~~~~~
There are two main problems currently facing users:
  1) There are lots of repositories available, with cross-dependencies
     and duplicated software.[2]

  2) The Application Manager's categories are badly implemented in the
     UI and *very* badly implemented by developers, meaning that "All"
     is the only real option to find software.[3]

There are a number of problems for developers which lead to this situation:
  1) Uploading to extras is by invite only, requires package signing and
     a number of other hoops to have been jumped through. Given how easy
     it is to set up a new repo on a web server, why go through the pain?

  2) Without proper QA, perhaps it is felt the software is too beta to be
     put in extras. (The creation of extras-devel will help here).

  3) There are separate repositories for each version of the OS. If the
     software is written in Python (say), it may be compatible across
     a number of IT OS versions.

  4) Downloads from the extras repository have no method of tracking
     number of users. At least with their own repository they can
     count the number of downloads.

These problems have been discussed a number of times, with suggestions
of auto-builders and a Debian/Ubuntu style of community maintainers.
However, to date, the best solution to come out of it is the
gronmayer.com repo database and a mass of third party repos. This
isn't much of a solution at all, with conflicting software, duplicated
packages etc.[4]


PROPOSED SOLUTION
~~~~~~~~~~~~~~~~~

Uploading
=========
An Ubuntu-style "Masters of the Universe" who act as gatekeepers for
extras and extras-devel, available to be used *OPTIONALLY* by
developers and package maintainers who wish to share their packages.

To reduce the workload of these community volunteers, the majority of
the work will be performed automatically, or with as much tooling
assistance as possible.

Developers/package maintainers won't *have* to upload directly to
extras or extras-devel. Instead, they willbe able register a package
or release for one or more IT OS versions through a website (such as
http://extrasupload.bleb.org/). This will be able to source the
packages to be uploaded a number of methods:

  * Direct upload of a series of debs (e.g. an app and its
    dependencies)

  * Monitoring a Garage project's files for new deb releases

  * Monitoring a web URL for new deb files.

Once a release has been identified it will be auto-QAed as much as
possible, with warnings or errors for these kind of things:

  * Section starts with "user/" (unless it's a lib or a
    dependency of another package) and is one of the
    pre-defined categories.

  * Name (without any punctuation) doesn't conflict with an
    existing package in any of the device's standard repos
    or the target repository.

  * Dependencies and versions won't prevent any other package
    from the standard or target repo from being installed.

  * Has an icon and a description.

Once these checks have passed, it will be passed on to the gatekeepers' queue.

Gatekeepers will be members of the community who have volunteered
through the website. Any one with karma over a given threshold (say,
100 for this example) will be auto-approved to be a gatekeeper;
otherwise special authority will be required (possibly through a
vouched-for system from another gatekeeper reviewing the user's
activity).

A gatekeeper will have associated with them one or more IT OS releases
corresponding to the OSes they have on their devices. When a release
is made for an OS which they have, an email will go out to the
gatekeepers asking for a volunteer, including basic details of the
package.

In the email will be a link, clicking the link will "claim" that
package's release for that gatekeeper. The gatekeeper will then do
further checks, including sanity checking descriptions and installing
the package on a device. After basic tests to the stability of the
software the gatekeeper will be able to do one of the following:

  * Fail the release. The maintainer will be notified of the
    reasons and the gatekeeper will include suggestions on
    improvements.

  * Demote the release. If the release was intended to be
    stable, but the gatekeeper finds too many bugs, they will
    be able to demote it to extras-devel, rather than extras.
    It will then be approved as if it was intended for
    extras-devel all along.

  * Approve the release. The gatekeeper will sign the package
    with their private key and upload it to extras or
    extras-devel as appropriate.

If a gatekeeper doesn't take one of these actions within some period
(say, 2 days) of claiming a package, the claim will be relinquished
and another gatekeeper will be able to authorise the package.

At any time, gatekeepers will be able to check the website for details
of all the packages outstanding, to whom they are allocated etc.

Future developments could also have the system updating
downloads.maemo.org automatically - but, for the moment, I think this
is outside of the scope of the project at the moment.


Metrics
=======
To allow developers/maintainers to track the usage of their packages,
popcon[5] will be ported to Maemo and users encouraged to install it.
This will also allow data to be fed into the karma system for number
of users of a developers' application.

Similarly, to encourage gatekeepers, a report of the number of
packages they have dealt with (whatever the outcome) will be made
available on the website in a machine-readable form for the karma
system to use.


NEXT STEPS
~~~~~~~~~~~
Assuming a consensus can be reached here on the outline of this plan,
the following is what I think needs to happen:

  0) Come up with a name for this overall process, the website
     and the gatekeepers.

  1) Register a garage project to manage the development of the
     website to handle the package allocation and gatekeeper
     details.

  2) Host that website somewhere.

  3) Port popcon to Maemo, feeding information into the website.

  4) Collaborate with the Maemo team to have the karma system
     read information from the website and update gatekeepers'
     karma and developers' karma from popcon.

  5) Publicise the opportunity to possible gatekeepers, and
     recruit them.

  6) Publicise popcon to end users, and the website and process
     to developers.

  7) Sit back, relax and watch the users rejoice in their wide
     selection of software, all high-quality and inter-compatible
     in the extras repo.

I'm happy to host the website (2) and be involved in all other stages.
But it's certainly more work than I've got time, and will require the
buy-in of many people to be a success.

What do people think? Before we press ahead with planning detail, I'd
like to iron out the kinks in the process; and technology obstacles
etc. It's also only worth while if developers and package maintainers
can see the benefit. Hopefully the ease of release and upload should
make it worthwhile. What do you think?

One thing worth bearing in mind, which is why I've CCed Quim directly:
if Nokia are planning on any form of improvement to the extras
process, based on the recent discussions, there is no point wasting
time on this. Clarification of Nokia's position on this would be
appreciated.

Thanks for reading this long email. Your thoughts would be very much
appreciated.

Cheers,

Andrew


[1] ...whilst in the shower: all my best thinking's done there. It
    may show ;-)

[2] http://lists.maemo.org/pipermail//maemo-users/2008-January/008824.html
[3] http://lists.maemo.org/pipermail//maemo-users/2008-January/008840.html
[4] http://lists.maemo.org/pipermail//maemo-users/2008-January/008837.html
[5] http://popcon.debian.org/

-- 
Andrew Flegg -- mailto:andrew at bleb.org  |  http://www.bleb.org/