Sunday 16 May 2010

Community Building for Maemo and MeeGo - What does the OBS *Do*?

In a closed environment you use what's in the SDK and you get your own little space; talking to others is discouraged and sharing and re-use outside the blessed area is frowned upon. This dictatorial style has the advantage of making life easier for the vendor. In an open world we have more interactions... and as students of networks know: increased connectivity brings increased complexity as well as increased benefits.  So this is an initial proposal for the organisation of OBS build projects and packages to support a QA process into an app-store / Extras or garage-like environment.  I'll introduce some basic OBS concepts and then describe how this might work. I would like this to raise awareness of some potential complexities that we may face and get some thoughts on how to deal with them. ...... Oh, and this is about both Maemo and MeeGo.

First an OBS Intro
  1. It's a build system (fully local) and a build service (like the autobuilder).
  2. You put source into it and say "use this repository" and it spits binary packages out.
  3. It builds a minimal and "clean" SDK using the repository you told it to use
  4. It has packages - a package corresponds to a tarball and a spec/dsc
  5. It has projects - a project is like a directory with packages
  6. Packages are 'published' into a corresponding repository (which can be shared with others)
  7. The published repositories can also be used by devices to download binary packages.

There is a lot more to it; scheduling, dependency based building, multiple architecture support, home projects, package signing...

The 'trick' then, is to set up a structure of projects that we can use to support the publishing and sharing activities that we need.

So What are our Goals?
We want:
  • to allow freedom for developers to develop;
  • to provide a great build service and SDK
  • to work with the core distro as much as possible
  • to provide excellent quality assured applications for our "app store";
  • and for MeeGo, to extend the core distro with a community supported area for libraries and packages that are depended upon by more than one application.

First thing we get: Individual Homes and PPAs
You'll start by uploading and building a package in your "home" directory (which can have a structure underneath it for multiple projects). This will allow you to build against any of the main distros; any group/community projects or even any other community member home projects. Oh, and they can use your code as a baseline too. Once built your code is automatically published to a repo on the
community downloads server.

This is a lot like the Ubuntu PPA solution.

At that point you can stop if you want. You have a complete set of repositories (1/subproject). No painful QA processes. No 'fragmentation'. But equally your repo(s) will needed to be manually added to a device in order for it to appear in any apt-get/zypper/yum etc.

A huge benefit here is that to get at a development version of an application you use a specific repository, not a mishmash of randomly unstable packages like Extras-devel.

For the pros: Community QA'ed Repository - Extras
If you'd like your application to appear in the Extras repo which is pre-installed on devices then you can submit to the QA process.

First you register for the package name, then submit your code to the distro promoter; there it is QA checked, copied to Extras:Testing, built, QA'ed again and becomes available in the Testing repository.

<here be dragons> The community testers then approve your code. </dragons>

(I know that's a contentious point - and I don't have an answer. I do however have confidence that we can solve the problem through collaboration and co-operation.)

Once approved the code is copied to the Extras:Stable repository for publication.

Conclusion

Much of this text is online at:
http://wiki.maemo.org/OpenSuse_Build_Service
(I really hate it when things get locked up in blog posts and forums)

How can you help?

Some tasks needed to get the OBS running:
  • OBS Installation - a detailed guide on how the system was setup.
  • Application QA Process on the OBS - a proposal
  • Setting up Fremantle - WIP - post to follow
  • Fixing the Fremantle SDK - mmmm
  • Setting up cross-building - started, not imported yet
  • An OBS Autobuilder queue - not started
  • Reporting - not started

Also see:

No comments:

Post a Comment