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

[From: Jason Edgecombe]

Andrew Flegg wrote:
> 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/
>
>   
+1 (or the maximum points that I have)

This sounds great, I would love to see this happen.

If I can get my shopping list app to a beta state, then I will use this 
process.

Sincerely,
Jason Edgecombe
Maemo user (N800, OS2007)
wanna-be maemo app developer.