First an OBS Intro
- It's a build system (fully local) and a build service (like the autobuilder).
- You put source into it and say "use this repository" and it spits binary packages out.
- It builds a minimal and "clean" SDK using the repository you told it to use
- It has packages - a package corresponds to a tarball and a spec/dsc
- It has projects - a project is like a directory with packages
- Packages are 'published' into a corresponding repository (which can be shared with others)
- 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:
Posts
No comments:
Post a Comment