We are supplying GNU/Linux based firmware for a lot of different systems, from embedded sector to large scale installations, and we fully automatized the build process of (binary) software packages and system images. For each individual system configuration, we now just have to set up an selection of packages to build in, with their versions and (if applicable) features to enable or disable. The actual building process is nearly completely done by our system builder, called Briegel .

To get this working, a lot of packages have to be fixed, mostly due broken build files (ie. vanilla autotools are not capable of clean sysroot'ed crosscompiling) or other more "formal" problems. Also, from time to time, there are some other hot fixes necessary, ie. for critical bugs or security issues.

Of course these patches take some time to get into the upstream, and many projects are quite conservative with their release policy. Until these patches are found in the next release, we need some consistent patch archive for our buildsystem, so all builds can run completely from scratch. This is what our patch repository is for.

What's the OSS-QM project about

By the observation that many upstream packages are lacking a hight quality release engineering, so releases often contain lots of errors and distros yet have to do massively redundant QM works, we've started to bundle this work in one project, called the OSS-QM project. Its goal is to provide fixed/QM'ed releases to upstream packages in a generalized fashion. This also includes an normalized scheme for version/release management and source retrieval, so these things can be fully automated in distro's build systems.

For more information read our current paper.

The OSS-QM project also aims to make packages conformant to our "Rules for distro-friendly packages".

Availability

Instead of maintaining single patch files, we maintain our own branches/tags in public git repositories. These are available at the canonical  location: git://pubgit.metux.de/oss-qm/$package

The repositories have a specific layout:

• The repository is designed to hold branches of different vendors (eg. distributions)
• Branch namespace format: <VENDOR>+"."+<package>+"."+<branchname> (normally, there's just a "master" branch)
• Tags namespace format: <VENDOR>+"."+<package>+"-"+<version> (note that the version numbers are normalized)
• A special vendor name "UPSTREAM" is reserved for the package's official upstream. These branches/tags either come from the upstream's repository or unpacked tarballs (maybe leaving off some autogenerated files)
• Another vendor name "METUX" is assigned to ourself.
• Vendor branches are always based on the recent upstream branches, tags are based on the upstream tag w/ same upstream release. (but there may be even smaller revisions, basing on the same upstream, eg. if some more fixups have been added later)

>>> List of current OSS-QM repositories

Using the oss-qm repositories:

If you're only interested in using our repository (eg. for an automated build system), just clone the repository and checkout the appropriate release tags. As the version numbers are normalized, this is fairly easy to automize. For example, if your buildsystem does not yet support  checking out directly from git, you can use a small shellscript to create tarballs (see: git-archive).

Feedback is welcomed to < Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. >

Contributing to oss-qm:

If you want to get your stuff directly into our repos, you first need an vendor name (eg. your distro, company, nickname, etc) - it has to be in capital letters (hyphen and underscore allowed :)) and tell us. We'll set up an sync mechanisms.

An sourceforge.net site is currently in process of being setup.

>>> SourceForge Site

Usage Terms

• The patches are, of course, available under the same terms as the original license defines.
• There is absolutely NO WARRANTY for anything about this patch repository
• Please avoid unncessary load. Dont scan the http server for new stuff, use git-fetch.
• Note that the actual server could be moving between different hosts anytime (eg. if we decide to mirror it using multiple A-records) - always use the canonical hostname.