This is a tentative description of how the process for changing OpenSlug works.
When and where OpenSlug releases are made
This page describes OpenSlug releases and explains how the different locations of the OpenSlug source differ.
All OpenSlug versions are available in source form. The binary releases are built from the source - there's nothing hidden or binary only. The source can be found in two places:
The three ways to get a working OpenSlug
The two source locations give two obvious ways to build OpenSlug. Building from the source tarball gives an OpenSlug identical to the corresponding binary release.
The third way of getting a working OpenSlug is to use
The monotone database
You must build from the source yourself. The result may not work - it may not work at all. After you have fixed any problems you should report the issues back to the #openslug IRC channel. You may also find that channel helpful in tracking down problems.
Ideally the monotone build should always:
This is all that can be expected of the monotone build. In particular packages in
The release and source tarballs
The released binary is a snapshot, possibly with local fixes, of the monotone tree. It is expected to have the following properties:
The last point is conditional on having adequate tests for the packages - in other words packages may have only received limited testing and bugs may show up with more advanced use.
There is no expectation that the packages listed in
Upgrading from the package feed
The release or a source tarball build may be upgraded using
An upgraded system does not change the flash image - it is, effectively, frozen at the original release. Repeating
Upgrading from the feed is the expected method for all OpenSlug users to upgrade.
The development and release processes
The reason for documenting a "process" is that this makes it clear what changes go where and how to handle errors. The aim is to ensure that developers can make forward process without preventing the work of other developers and without harming user systems.
All developer changes are committed to the org.openembedded.dev branch of the monotone database. This development branch is shared with the rest of the OpenEmbedded developers, so be careful what you touch in it.
The unstable package feed is built from this branch and it is therefore only suitable for testing!
Changes checked in to the development branch should leave the branch with the following properties:
That is it.
Bumping the PR is very important If the PR is not bumped after a package change (any package change) there will be two versions of the package with the same version number. This must not happen with releases and should not happen in the monotone database. There are very few cases where it is ok not to increment the PR:
Releases don't change. When a release is to be made the process is as follows:
The development branch does not freeze during a release. If necessary a separate branch may be made.
The release package feed
Packages get incorporated into the feed from the monotone head. This is very similar to a release - a fixed monotone revision ID may be used for testing the relevant packages.
The package manager may also use a monotone branch to manage this process. After the SVN release has been made the original branch, if constructed, is not required, therefore the package manager can simply propagate changes from the development branch into the release branch as required.
Changes will be committed which break booting or packages. Such changes need to be fixed in the correct place.
monotone changes which render stock systems unbootable should be fixed as soon as they are noticed. Responsbility for this relies with all the developers, regardless of who checked the change in.
It is reasonable to back out (monotone
If a change was really the wrong way to do something and if the right way wouldn't cause the problem disapproving the change is correct.
Broken package builds
If a change breaks a package build and the package is not required for
If a package builds but does not execute correctly a bug-report should be sent for the package.
This includes packages required by