[Jaffa Software]

Sunday, 13 January 2008

Solving the lack of QA and muliple repositories problem

I've just sent an email to maemo-developers asking for feedback on an idea:

RFC: Proposal to solve multiple repository, poor QA situation

There is an increasingly acute problem with the Internet Tablets, the number of repositories a user has to install to correctly get some software is growing. It has been regularly discussed on maemo-dev that the best thing to have would be for all packages to be in extras - especially since in OS2008 it is now included by default (albeit disabled).

I fear that the gronmayer.com database of repositories - no matter how useful it is - will only exacerbate the situation.

What I'm suggesting is an easy way for developers to upload to extras, with a group of volunteers doing the legwork of signing and uploading the packages, doing quality assurance and so on.

This should make it easier for developers (no need to have their own repos any more), and easier for users since they'll only need to enable the extras repository and know that none of the software in there will brick their device, be uninstallable etc.

The QA will also allow users to use the categories of the Application Manager more, as the gatekeepers will strictly limit the categories that are used by the packages flowing through them.

Of course, this system will be voluntary: I'm in no position to dictate that everyone use it, but hopefully there'll be sufficient benefits to everyone to make it a viable scheme.


  1. This is the zaurus situation from 5 years ago all over again. To overcome it you must be able to convince users that everything they want is in the preconfigured feeds (iirc extras is present, but disabled in IT2008) and actively contact people with personal repo to submit it to the gatekeeper system.
    Ideally only .dsc files are shuffled around, but initially people can shuffle .deb around directly.

  2. I think we've just witnessed what happens if we trust Nokia with our data...

  3. I think a simple way to upload package is needed. Like a simple html form with an upload which upload a .deb to the extra repository.

  4. The best is to use something like Ubuntu/Launchpad. They provide what they call PPA, where you can use "dput" tool to upload a source package that will later be compiled and transformed into a debian package and added to their repositories. It will be quite easy to make this for Nokia, since the PPA and Launchpad are open source. It will be also useful for the developers, because it takes care of compilation for them.


  5. Peter, Launchpad is not open source.

  6. I am using ArchLinux, and I like AUR (ArchLinux User-community Repository) which mostly solves similar problems:

    Everyone can upload "package descriptions"", which are simple text files. Those files can be marked as "trusted" by distro gurus (they are initially "untrusted"), or reported as out-of-date by users. But the best thing is that it really unified different repositories which existed before, so it is easy do create command-line tools to look for new packages.
    Look at the "AUR User Guidelines" and "AUR TU Guidelines" for inspiration.

  7. I see two distinct issues/goals -- how to promote:

    1) Improved quality control
    2) Easier submissions to centralized repositories

    The status quo of repositories reflects the reality of the community; Lots of apps to be ported; few people porting, developing and packaging (and many of those people only marginally qualified for the job).

    An imaginary solution - hire a crack team of qualified debian packagers working full-time to identify ports, do QA and needed adjustments before hosting on a central repo - would solve both problems in one swoop.

    In the real world of finite resources, I think one can only repeatedly point-out the (very good) maemo packaging/porting documentation to developers/porters and encourage them to follow the guidelines.

    However, it is important to see the two issues involved as distinct: Implementing an easier repository submission mechanism does not necessarily help improve the QA issue. QA can not be automated, and creating proper hildonized and debian/ITOS -compliant versions of things takes time and effort which must either be voluntary or paid-for.

    Speaking for myself, I enjoy identifying games/emus that *can* run on tablets, and building/tweaking them to run well. This is what *I* enjoy doing. If there is a an accompanying 'service' to the community - it is in showing other enthusiasts what *can* be run, and providing the binary to prove it. While I acknowledge the value of solid, polished releases, that 'last mile' of work takes a LOT of time. And unless someone pays me money, they don't get to determine *my* use of *my* time.

    Any person who compiles an app for the tablets acquires neither the exclusive privelege to distribute it, nor the obligation to meet any quality standards, nor the obligation to host it anywhere in particular.

    If *you* want to port or improve any package and host it on extras, then by all means, feel free to do it.

    In summary, I laud the maemo.org people's work in documenting the process and encouraging contributors to make quality releases. All they should and *can* do is more of the same.

  8. Pupnik's comments are correct. In fact, ease-of-upload and robust-QA can and tend to be at complete odds with each other. Rule of thumb is, any time you make something easier/faster for a provider, QA becomes more problematic. That is true in almost any scenario. So, yes, the goals (and action plans) may need to be distinct BUT highly cognizant of each other.