Software ECO process

  This page is monitored by the OLPC team.

DRAFT Operating System Release Process

Patch Release Process

From time to time, there may be critical bug fixes that must be released before the next normal, scheduled releases. These can occur due to security issues, from unexpected hardware problems, or the discovery of latent bugs that affect large numbers of users.

Proposals for Patches

Proposals for patches will be submitted to the "eco-software" mailing list, with a bug number in the trac system. This bug must describe:

• the nature of the issue, and any trac bugs providing useful information
• the believed urgency of the fix, including any deadlines
• the patch(s) for review, if not clearly stated in referenced bugs
• the consequences of not fixing the problem
• an estimate of the number of affected people
• how they are affected, and how seriously they are affected
• who has reviewed the patch(s) for correctness (preferably at least three people competent in the area affected)
• whether the problem has been tested in a development build, and for how long
• how the patch has been tested
• whether the patch should enter Quanta's manufacturing stream and why (there may be circumstances where it is not appropriate to update the build being used in manufacturing)
• and how the fix can be verified in the resulting build.
• the eco-software mailing list should be in the cc: field of the bug.

Discussion can then ensue in trac. If there is no consensus that the patch should be deployed, a decision will be made by Jim Gettys, Kim Quirk, and Walter Bender.

Security patches cannot, unfortunately, follow this path due to disclosure rules, but will occur in a similar fashion on a closed security mailing list.

Proposals for a Patch Release

Proposal for a patch release will also be made to the "eco-software" mailing list, enumerating exactly which bug(s) will be closed. When approved (?what should constitute approval)? patch builds will begin.

Testing of the Patch Release

1. The release master will then put together a candidate build
2. The problem the fix ostensibly fixes will be tested using the information contained in the trac bug(s)
3. Upgrades at least from the previous signed release (and previous signed release?) are successful. (should we explicitly compare the result of the upgrade against a fresh installation?)
4. The 1 Hour Smoke Test must be performed, both using a fresh installation and an upgraded installation, looking specifically for regressions from the release reports, and thinking about possible interactions a fix might cause.
5. More than one SKU and keyboard type are to be used during this testing, to catch regressions in keyboard identification
6. When time permits, test builds should be used for testing by developers in the field to confirm the fixes.
7. If new problems (not previously known as part of testing or bug reports) are discovered during the test process, they must be analyzed to root cause and the eco-software mailing list informed of the findings, and a new decision made on proceeding. These would normally be latent bugs, and the criterion for proceeding (waiving) the bug should be based on a judgment that the patch build is at a minimum no worse than the previous build

Signing of Builds for Release

Release Checklist

1. The testing of the patch release succeeded or a newly discovered problem waived (per above)
2. All source packages are present and accounted for
3. All packages were build on the correct OLPC controlled build system(s)
4. Only packages fixing the referenced bug(s) are changed by the build that is to be signed
5. The patch candidate has been installed on MP, CTest and B4 systems successfully
6. Was the correct version of OFW included in the build?
7. Whenever practical, the build will have also been tested by a significant number of users in the field to confirm the fixes are correct.

The build master is responsible for ensuring the checklist and that the process has been followed.

Signing a release requires a majority quorum of: Jim Gettys, Walter Bender, Dennis Gilmore and Ivan Krstic.

Final Steps

Note that signing the build for release is not the end of the process: the signed release must see a final verification step on write protected systems.

The final steps are to be performed in order:

1. sign the build, generate known checksums
2. test its installation on a write protected MP system. Also test an installation on B4 systems.
3. If everything is fine, then the signed build can be made available in the normal location for signed builds.
4. Notify the Quanta ECO mailing list, if indicated, preferably using signed email, and certainly containing checksums of the build.