Release Process

Release Process Overview

Special thanks to Charles Merriam for helping show the way
http://lists.laptop.org/pipermail/devel/2008-April/012318.html

This is a first draft. Please send comments, questions and suggestions to greg at laptop.org

The following is OLPC's suggestion for a new release process. Please comment, question and improve as needed. Gregorio 08:46, 27 June 2008 (UTC) (UTC)

The goals of this process are:

- Ensure high quality releases which meet the needs of users in a timely fashion.
- Maximize the participation, productivity and enthusiasm of the open source community.
- Create a predictable process on which users and developers can use to plan for future work.

This process does not cover activity development. It only covers "core OS" (full list of modules tbd).

Time-based Releases

A Release consists of set of builds, documentation, an approved ECO, a completed checklist (add URL) and support as defined below.

For example, the most recent Release as of this writing --Greg 14:09, 25 June 2008 (UTC) is 8.1.0. It is documented here: http://wiki.laptop.org/go/OLPC_Update.1_Software_Release_Notes

Each release will have a page linked from here:
http://laptop.org/teamwiki/index.php/Releases

Major Releases (e.g. 8.1.0, 8.2.0, 9.1.0, 9.2.0)

Major updates which include significant new features will be released twice a year (one in the first half of the calendar year and one in the second half of the calendar year).

Each major release will be supported for a period of 1 year from the time the release process check list is complete: http://wiki.laptop.org/go/USR_Checklist The date in the "Release team final sign off" field defines the start of the 1 year support time frame.

Support means that a minor release with bug fixes will be built at OLPC's discretion based on an discussion with customers and other stakeholders.

Minor Releases (e.g. 8.1.1, 8.1.2, 8.2.1, 8.2.2)

Minor releases will focus on bug fixes and will come out as often as negotiated by customers and OLPC. Minor releases may include new features if the release manager and primary customers agree they are well tested and documented. Minor releases must be fully backward compatible with the major release that they are based on. That is, activities and APIs must continue to work as before.

An example of a minor release would be the addition of support for an additional language.

All the bug fixes and changes in a minor release will be tracked and recorded in a software ECO and included in the release notes. See the full minor release process definition at: http://wiki.laptop.org/go/Unscheduled_software_release_process

The choice of time based releases is motivated by the its success in a growing number of open source projects. For examples, see the Ubuntu (https://wiki.ubuntu.com/TimeBasedReleases) and Gnome projects (http://live.gnome.org/ReleasePlanning)

Types of Builds

Each build consists of core OS which implements a feature set such as http://wiki.laptop.org/go/OLPC_8.1.1_Features. At the option of the build author, the build may or may not contain activities.

One way of classifying a build is to identify its readiness to be a Release.

There are four types of builds in that classification:

1. Released images - (a.k.a. "stable") with release notes and ECO. This is a signed image which does not need a developer key to install on an XO. (e.g. official-703; the OS component of the 8.1.0 Release)
2. Release candidates - (a.k.a. "testing") release candidates which are in change control and may become official releases if it passes the test cycle. (e.g. candidate-708; tentatively the OS component of the 8.1.1 Release )
3. Development images - (a.k.a. "unstable") - the latest image with the latest code but it is also likely to contain significant bugs. (e.g. joyride-2072)
4. Experimental images - images which are not expected to work and which are used for creating major new functionality; typically a part of "topic branches". (e.g. faster-2072)

More details on available builds and how to get them are here.

See also http://wiki.laptop.org/go/Build_system.

For a developer wanting to contribute new code we recommend the following steps:

1. Decide whether you want to hack on activities, releases, bugs, or experimental features.
2. Choose the corresponding build type: released images, candidates, development images, or your own topic branch.
3. Send an e-mail to devel@lists.laptop.org and/or sugar@lists.laptop.org explaining your work and gathering feedback.
4. Implement a basic first pass which compiles and shows the main idea. Post a link to its source to the same lists, preferably in a patch-like format.
5. Revise as needed based on feedback.
6. If possible, get the changes included in an upstream repository or, as appropriate, ask the list for details on how to package it locally for the XO.

Release candidates are the builds that may replace the current 'stable' designation. Release candidates are created during the execution of software engineering change orders. See details of ECO creation steps here http://wiki.laptop.org/go/Unscheduled_software_release_process and Example ECO for 8.1.1

Note: each successful build generates products that can be installed on some system. For example, release builds contain disk images suitable for flashing to NAND, for consumption by OLPC update, for inspection on other systems, and for simulation in QEMU. Traditionally, important builds are announced on devel@lists.laptop.org.

Release Naming Convention

The release names are of the form "Y.H.NN"
Y = target calendar year
H = major release number representing calendar year half (1 or 2)
NN = minor release number

Examples
8.1.1 First major release in CY08, maintenance rebuild 1.
8.2.0 Second major release in CY08

Recall that releases consist of a family of builds derived from a reference OS, along with "polish" like documentation, signatures, &etc.

This build family consists of a reference OS named:
- official-nnn
which lives on http://download.laptop.org/xo-1/os/official/. The word "official" means that it is a Release build (link to doc, etc.). The "nnn" is an integer uniquely identifying the source code. An example is official-703.

Derivative builds may be created locally by anyone. However, crypographic signatures are required to enable "cheap" mass installation of the derivatives. No signatures are required if you are willing to use OLPC-supported USB customization technology or if you request developer keys for all your machines.

Derivative builds are named as follows:
- variant-nnn-n
The "variant" field is typically a short string identifying a deployment or language group such as "peru" or "en". When the build name does not start with "official" it means that either:

• the reference operating system was customized to produce a derivative build, in which case the name will be as above, or
• a fork has taken place.

Examples:

For example, peru-703-6 is the customized build created for Peru based on the source code identified by 703. Another example is en-708-1 which is the English language customization of build 708. This is not an official Release unless and until official-708 is released and it is documented on the release page.

Release Schedules

Getting a stable build out can be hard. A branch grows in stability over time and stability of the release and field testing the final release candidate takes time.

Step 1 - New Major Release is named.

Step 2 - Release objectives and lead customer identified. Target features listed and target date down to the month is chosen.
The module maintainer, with his peers and the community comes up with a set of features for the release. Product Management participates in the discussion and informs it based of customers feedback. Product Management and the relevant module maintainers are responsible to build consensus. The module maintainers are responsible to ensure that the code going in git repositories is consistent with that consensus.

Step 3 - Schedule is posted as follows.

"Change Control (CC) of X" means that you need to convince the maintainer of X to merge your change instead of pushing it yourself.

• 45 days before target date CC of Features.
  
• 30 days before target date CC of the Release.
  
• 15 days before target date CC of the Release Show Stoppers only
  
• <15 days before target date Get consensus from test community, QA, and engineering. Then finish release check list.
  
• Release day - Kim sends announcement e-mail approving release for production.
  

Defintions

• CC of Features

After this date only new features which are approved by module maintainers and Product Management are allowed in. Bug fixes can still be added without approval for another 15 days. All strings must be final by this time. All user interface changes must be final by this time.

• CC of the Release

All translation packages must be final by this time.
On or before this date Module maintainers propose a set of bug fixes to get into the stable branch. They usually do so by releasing a new version of their module and informing the release team about the changes it contains and the steps necessary to test those. The release team will make sure that the relevant QA is executed and either approve the changes or ask for fixes/improvements. As soon as the changes are approved they are added to the stable build. After this date no changes are allowed in to the code without the approval of the module maintainer and the Release Triage team.

• CC of the Release Show Stoppers

As of this date every single change to the source code needs to be approved by the Release Team before it happens.

Release Steps

Minor Releases follow the process outline here:
http://wiki.laptop.org/go/Unscheduled_software_release_process

In particular a Release must complete the checklist:
http://wiki.laptop.org/go/USR_Checklist

A Major Release follows the process documented here:
http://wiki.laptop.org/go/Plan_of_Record-2008/Draft_3#RM:_Release_Mechanisms

Release Goals and Request Prioritization

TBD.

Existing thinking on the current plan is here
http://wiki.laptop.org/go/Plan_of_Record-2008/Draft_3

Summary and Open Items

The OLPC Build Process is getting cleaner, faster, and more reliable. The new time-based release cycle provides the regularity needed by developers and users.

Open items needing definition

• Fill in the schedule
• Define feature and bug prioritization process
• Define release quality metrics and include test details and milestones
• Governance and community best practices guidelines
• Gather community buy in and consensus
• Finalize release and triage teams
• Review and finalize release details pages:
• Put it in to practice, revise and improve