|Reported by:||cscott||Owned by:||cscott|
|Priority:||high||Milestone:||8.2.0 (was Update.2)|
|Component:||distro||Version:||Development build as of this date|
|Keywords:||test-suite||Cc:||mstone, dgilmore, kimquirk, jg, marco|
|Deployments affected:||Action Needed:|
OLPC builds should have the following stages:
1) Repository collection.
Both koji and joyride-related repositories should be collected into a git archive. By building from git instead of directly from koji, we both speed up our builds (by hosting the files locally) and insulate ourselves from koji/connectivity failures which would otherwise interrupt our builds. We also ensure that the full set of bits (source and binary) which make up our builds are archived locally and permanently accessible. The separate collection step also allows us to side-step koji in the rare cases where it is necessary, and to provide better repository commit messages in the run-up to a stable release.
1b) Joyride collection should include rebuilding SRPMs in an appropriate mock chroot, to ensure that our binaries match our sources and that binary incompatibilies don't sneak in.
2) Package composition (aka "the build", aka "pilgrim").
Composition takes place with yum targetted at the collected repositories.
3) Automated build testing. (aka, "tinderbox")
After each build, an automated test suite is run which (a) protects against regressions, (b) ensures that the build was "correct" (ie, pilgrim didn't fail), and (c) to the greatest extent possible, ensures that all released builds, even development builds, are at least dogfood quality.
At some future point, automated reverts of the package collection might occur if new builds fail the automated test suite. Alternatively, we can automatically graduate packages from 'development' to 'testing' if a certain period has passed without a blocking bug filed against the package. (This latter plan requires greater integration of our build system and bug database.)
Builds which pass the automated tests are installed to the appropriate directory on downloads.laptop.org (see trac #5038 and #1813). Builds which don't pass automated tests might be made available in some appropriate "unofficial" spot to aid correction of the failures, but this spot should not be visible to the general public. Installation may also involve updating the updates.laptop.org database so that (for example) the 'joyride' stream always points to the latest joyride build.
This trac item will be a meta bug for:
a) discussion of this process,
b) creating appropriate wiki pages documenting the process in detail,
c) referencing specific trac items for the various work required to fully implement this system, and reporting on progress.