Release Process: Difference between revisions

From OLPC
Jump to navigation Jump to search
 
(65 intermediate revisions by 11 users not shown)
Line 1: Line 1:
{{Developers}}
= Release Process Overview =
{{Translations}}
This page describes OLPC's software release process.


== Goals ==
Special thanks to Michael Stone for creating most of the existing pages and spending time getting me up to speed on how its done now.
The goals of the release process process are to:


# Ensure high quality releases which meet the needs of users in a timely fashion.
Also to Charles Merriam for helping show how good it can get <br>
# Maximize the participation, productivity and enthusiasm of the open source community.
http://lists.laptop.org/pipermail/devel/2008-April/012318.html
# Create a predictable process which helps users and developers plan for the future.


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


The output of this process is a generic software image suitable for installation on OLPC's XO laptop platform. The image is generic in the sense that it includes a rounded selection of activities, applications, and languages.
[[User:Gregorio|Gregorio]] 08:46, 27 June 2008 (UTC) (UTC)


We do not expect established deployments to use this software image directly. Almost all deployments have needs or desires to customise the software image that they ship (e.g. with new languages, a different selection of activities, specific default settings, etc.). We expect that most established deployments will use the [[Build system]] to produce a variant of the release including their own customizations.
----


Nevertheless, the process of developing and stabilising the generic release is key, as it forms the base of all the deployment-customized software releases.
The goals of this process are to:


== The process ==
- Ensure high quality releases which meet the needs of users in a timely fashion. <br>
- Maximize the participation, productivity and enthusiasm of the open source community. <br>
- Create a predictable process which helps users and developers plan for the future. <br>


Each release is planned in advance, and this process results in a slightly different development/release methodology for each release. However, certain guidelines and well-established principles are stuck to:
== Time-based Releases ==


* The release planning documentation is made public from the start.
A Release consists of a set of builds, documentation, an approved [[Unscheduled_software_release_process|engineering change order]] (ECO), a completed [[USR_Checklist|checklist]] and support as defined below.
* Release development is divided into individual stages, separated by milestones (discussed below)
* Releases are coordinated according to a schedule of milestones, which is decided early on, and included in the release plan.
** This is important so that our customers know when to expect the final release, when they should get involved with development and testing, and to allow them to plan their upgrade/rollout.
** This is also a well-established practice in our neighbouring open source communities
* The release schedule is honored strictly. That is, the milestone dates are adhered to, even if some sacrifices (such as exclusion of planned features which didn't arrive in time) are made. Some flexibility can be allowed for, but these should be exceptional cases only.


The development process is divided into distinct stages, with milestones to mark the progression from each one to another. '''Each of the items below links to an extensive explanation (including technical and managerial procedures) of each stage''', be sure to read them all if you want to become involved in the release process.
For example, see [[OLPC_Update.1_Software_Release_Notes|8.1.0 Release Notes]], the most recent Release as of this writing
# [[Release Process/Planning]]
[[User:Gregorio|Gregorio]] 14:21, 27 June 2008 (UTC)
# [[Release Process/Development]]
# [[Release Process/Stabilization]]
# [[Release Process/Release]]


== Major and minor releases ==
'''Each release will have a page linked from the [[Releases|Releases page]]''' <br>


Major releases include large platform changes (such as updating to the latest versions of Fedora & Linux) and addition of new features.
Time-based means that we have a target release day well in advance. It also means that we have a plan to begin the final test on a specific day. It does not mean that the release is guaranteed to be complete on the target release day. Features and non-critical bug fixes will be deferred to make the release day. However, a minimum standard of quality as defined by the [[Unscheduled_software_release_process#Release_Team|Release Team]] must be met before the release is final. The release will be delayed until that minimum quality standard is met.


Minor releases (a.k.a. point releases) are limited to the fixing of bugs which are affecting deployments, and occasionally include translation and locale updates (requested by deployments).
The definition of a minimum quality standard must be worked out and refined over time in consultation with customers and developers. It should be a priority of development and test teams to define that in advance and codify it as effectively as possible.


: This was previously adhered to quite strictly, but the recent minor releases in the 10.1 series have seriously blurred the lines between major and minor releases. This degrade of practice started when OLPC's development resources were downsized, meaning that there were no resources in sight to allow for a future major release, resulting in the relaxing of criteria on what could go into the minor release. However, now that OLPC's software team has grown a bit again, it is my hope that this previous practice can be restored, so I've documented it that way. Time will tell... -[[User:DanielDrake|DanielDrake]] 17:22, 9 February 2011 (UTC)
The choice of time based releases is motivated by its success in a growing number of open source projects. For examples, see the [http://fedoraproject.org/wiki/Releases Fedora], [https://wiki.ubuntu.com/TimeBasedReleases Ubuntu] and [http://live.gnome.org/ReleasePlanning Gnome] projects.


=== Major Releases ===
== Features ==


New major releases will include a set of new features, pioneered and developed by OLPC staff and community members. A feature is defined as a significant change or enhancement to the current version of XO software that may or may not include new packages. Our feature process should be driven by the needs and feedback of our customers (deployments) and our users (young children).
A Major Release includes significant new functionality. There will be two Major releases a year.

Major Releases will include bug fixes and new features (as opposed to Minor Release which should only include bug fixes).

A feature is defined as a significant change or enhancement to the current version of XO software that may or may not include new packages.


Features are usually considered to meet one or more of the following objectives:
Features are usually considered to meet one or more of the following objectives:
Line 47: Line 53:
# Exciting new capabilities we can trumpet.
# Exciting new capabilities we can trumpet.


Some examples might include: <br>
Some examples might include:
* New educational tools that will be used by children <br>
* New educational tools that will be used by children
* New features from upstream that we are making available on the XO for the first time <br>
* New features from upstream that we are making available on the XO for the first time
* Improvements to tools and infrastructure used by activity developers <br>
* Improvements to tools and infrastructure used by activity developers


OLPC plans which features to develop for each release according to its key principles and based on feedback from customers. During planning stages, a discussion will usually be started on the devel [[Mailing lists|mailing list]] in order to solicit input from the community, and to clearly communicate that the feature planning process is underway.
==== Duration of Support ====
Each Major Release will be supported until two months after the second following Major Release is available. For example, 8.2.0 will be supported until 9.1.0 two months after 9.2.0 is available. That assumes that 8.2.0 is followed by 9.1.0 and 9.2.0. The date of when a release is "available" is set by the completion the "Release team final sign off" field on the [[USR_Checklist|Release Process Checklist]].


Features can also enter releases through upstream projects. For example, a new feature added to GNOME will automatically enter an OLPC release once a release is made including that specific GNOME version. Some of these features may have direct impact on OLPC and are good candidates to be discussed in the release notes.
The intention is that Major Release will be supported for at least 14 months. If the first iteration of a Major Release needs a Minor Release update right away (e.g. 8.2.0 comes out in August and it has problems so 8.2.1 is released in September), OLPC will encourage deployments to use the latest Minor Release but the date of posting of the Major Release will still determine the duration of support. That is 8.2.x will be supported until two months after 9.2.0 is available.


Features outside of OLPC's feature plan are also welcome to be contributed by interested individuals and deployments, providing that they meet the normal code acceptance criteria (open source, good code quality, good documentation, appointed maintainer, ...), and provided that they are accepted and included within the acceptable stages of the release schedule. In many cases, development of such features does not belong at the OLPC level, but rather in the upstream projects (for example, development of a new Sugar feature would fall entirely within the SugarLabs community, and would not need acceptance or review by OLPC).
So at any time, OLPC will need to support two releases (e.g. 8.2.x and 9.1.x) and after the availability of a new Major Release OLPC will need to support three release for two months (e.g. 8.2.x, 9.1.x and 9.2.x). So if a critical bug fix comes up right after a new release (e.g. a security fix) and there are important users on each available release, OLPC will need to add the patch to three images and make three new Minor Releases (e.g. 8.2.4, 9.1.3, 9.2.1).


== Maintainability and sustainability ==
==== Meaning of Support ====
"Support" means that OLPC will consider releasing a Minor Release to address critical bug fixes needed by deployments. After the end of the support period, OLPC will endeavor to include needed bug fixes in the latest available release. The criteria for when OLPC makes a Minor Release available is defined in [[Release_Process_Home#Minor_Releases]]


OLPC has historically made quite a few changes to standard open source software technologies (Linux, Fedora, etc) and this hurts us in every release cycle. We are now a small team and every release cycle we spend a lot of time bringing forward the the collection of OLPC-local changes.
Support also means we will work with upstream to understand and resolve security issues, and we will track, recreate and understand critical customer issues. New features and capabilities will not normally be included in Minor Releases. Each Minor Release must be fully backward compatibile with the Major Release on which is it based. All activities and feature which currently work will continue to work in the same way after upgrading from a Major Release (e.g. 8.2.0) to a Minor Release based on it (e.g. 8.2.1).


In recent times, this "delta" from upstream software has been greatly reduced. We need to keep working in that direction, which means strict controls on any new non-upstream changes being added. The most effective way to approach this is to get your changes upstream first.
See also definition of Minor Release criteria (add link).


== Version numbering ==


=== Release names ===


The release names are of the form "Y.H.NN"
=== Minor Releases ===
* Y = target calendar year

* H = major release number representing first release or second release of the calendar year
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 reason for generating a Minor release would be to add support for an additional languages.

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

==== Criteria for Delivering a Minor Release ====
A Minor Release will only be considered if it affects users.

A Minor Release will be considered if it makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package.

A Minor Release will not be considered for new functionality. Developers should implement new functionality in the next available Major Release and users should plan on waiting until the next Major Release for new functionality (AKA features). One notable exception is the need to add support for a new language. A new language will be considered for a Minor Release if a new deployment with a new language plans to deploy before next Major Release will become available.

Minor releases take away scarce release manager, QA, and engineering time, and thus should be avoided absent compelling reason. Any bug fix or security update which may cause a Minor Release to be generated will be evaluated for how likely it is to happen; how many people it would affect; and how much disruption the fix causes to the rest of the code base.

Before deciding to add code to a Minor Release, developers should ensure that the change addresses one or more of these issues: <br>

* A truly critical functionality problem
* The package becomes uninstallable
* A released architecture lacks the package



= Release and Build Naming Conventions =

== Release Names ==

Recall that Releases consist of a family of builds derived from a reference OS, along with "polish" like documentation, signatures, and installable images. It is assumed that end users including students will use a Release.

The release names are of the form "Y.H.NN" <br>
* Y = target calendar year <br>
* H = major release number representing first release or second release of the calendar year <br>
* NN represents the Minor Release, starting with .0 at the availability of the first Major Release and going up by 1 for each publicly available minor release after that.
* NN represents the Minor Release, starting with .0 at the availability of the first Major Release and going up by 1 for each publicly available minor release after that.


A Major Release and all its derivative Minor Releases can be referred to with a variable (or wildcard) in the third digit (e.g. 8.2.x refers to 8.2.0, 8.2.1 and 8.2.3).
A Major Release and all its derivative Minor Releases can be referred to with a variable (or wildcard) in the third digit (e.g. 8.2.x refers to 8.2.0, 8.2.1 and 8.2.3).


Examples:
Example Names <br>
* 8.1.1 First Minor Release rebuild based on the first Major Release in CY08 <br>
* 8.1.1: First Minor Release rebuild based on the first Major Release in 2008
* 8.2.0 Second Major Release in CY08 <br>
* 8.2.0: Second Major Release in 2008

Major and Minor Release will have code names before they are released.

== Build Names ==
Recall that Releases consist of a family of builds derived from a reference OS, along with "polish" like documentation, signatures, and installable images. It is assumed that end users including students will use a Release.

The build family consists of a reference OS named: <br>
'''official-nnn''' <br>
which lives on http://download.laptop.org/xo-1/os/official/. The word "official" means that it is a final Major or Minor 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, cryptographic signatures are required to enable "cheap" mass installation of the derivatives. No signatures are required if you are willing to use OLPC-supported [[Customization_key|USB customization]] technology or if you request developer keys for all your machines.

Derivative builds are named as follows: <br>
'''variant-nnn-n''' <br>
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.

For example,

[http://download.laptop.org/xo-1/custom/peru/peru-703-6/ peru-703-6] is the customized build created for Peru based on the source code identified by [http://download.laptop.org/xo-1/os/official/703/ 703].

and

[http://download.laptop.org/xo-1/custom/g1g1/en-708-1/ en-708-1] is the English language customization of release candidate build [http://download.laptop.org/xo-1/os/candidate/708/ 708]. This is not an official Release unless and until official-708 is released and it is documented on the release page.

:''I find this section confusing. The bits on an XO are a combination of a core OS plus an activity set. The peru-703-2 build was intended to denote that "core OS" 703 was combined with "version 2" of peru's activity set for that core. The "en-708-1" name seems to be too brief; it should be something like "g1g1-en-708-1" to more clearly indicate that it is the english language version of the "g1g1" activity set (that is, the activities provided to the original g1g1 participants). Presumably the "en" was intended to reflect that we might add different activities for future European g1g1 participants?
:''In any case, I believe this nomenclature was a mistake. We should not be exposing the raw build number of the core OS; we should be providing names like "peru-8.1-2" instead. This also reflects the fact that Peru's activity set is not likely to require change when 8.1.1 is released, since minor releases should maintain API compatibility.
:''Finally, the discussion in this section seems to anticipate the fact that some countries might fork the official OLPC core OS to varying degrees, and proposes a naming system for this which is confusingly similar to the names given to "official" core + activities set. If names for forks are required, I think we need to revisit this naming system altogether to avoid confusion. Perhaps '8.1+peru-2' is a better base name; a forked uruguay build based on 8.1 might be called 'uruguay-8.1+uruguay-3' or perhaps we should just encourage using an unrelated name like 'uruguay-1.0+uruguay-3' to avoid confusion with the "official" 8.1. --[[User:CScott|CScott]] 02:15, 29 June 2008 (UTC)

= Types of Builds =

Each build consists of a core OS.

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

There are four types of builds in that classification:

# 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)
# 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 )
# 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)
# 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 [[OS_images|here]].

See also: [[Build_system|build system]], [http://www.us.debian.org/doc/developers-reference/ch-resources.en.html#s4.6.4 Debian descriptions of stable/testing/unstable/experimental].

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

# Decide whether you want to hack on activities, releases, bugs, or experimental features.
# Choose the corresponding build type: released images, candidates, development images, or your own topic branch.
# Send an e-mail to devel@lists.laptop.org and/or sugar@lists.laptop.org explaining your work and gathering feedback.
# 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.
# Revise as needed based on feedback.
# 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. One useful link on including packages in Fedora is [http://wiki.laptop.org/go/Developer/Fedora#Outside_Reading here]

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 in the [[Unscheduled_software_release_process|Release Process page]] and [[OLPC_SW-ECO_5|An 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 Steps and Schedule =

== Steps to Create a New Release ==
Step 1 - New Major Release is named. <br>

Step 2 - Release objectives and lead customer identified. Target features listed and target date down to the month is chosen. <br>
The module maintainer, with his peers and the community comes up with a set of target 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. <br>

Step 3 - Schedule is posted per below <br>

== Schedule and Milestones ==
All announcements in refered to below will be sent to the Devel list at devel@lists.laptop.org and Localization list at localization@lists.laptop.org

0 Start Release Process '''Set Target Date and Name''' Pick the target date and name the release. <br>
# 95 days before target date Announce '''Steam Milestone''' coming in 5 Days. . <br>
# 90 days before target date Announce '''Steam Milestone''' achieved. Steam level Release Candidate Finalized <br>
# 65 days before target date Announce '''Water Milestone''' coming in 5 days. Water level Release Candidate chosen <br>
# 60 days before target date Announce '''Water Milestone''' achieved. Water level Release Candidate finalized <br>
# 35 days before target date Announce '''Ice Milestone''' coming in 5 days. <br>
# 30 days before target date Announce '''Ice Milestone''' achieved. <br>
# <15 days before target date Announce start of '''Final Test'''. Ask test community, QA, and engineering to report results and give +1 or -1 on Release Candidate being released
# Release day. '''Announcement Day'''. Make sure that release process check list is complete [[USR_Checklist|Release Process Checklist]]. Once signed off, Kim sends announcement e-mail approving release availability <br>

=== '''Steam Milestone''' ===
Prior to ''Steam Milestone'', there is great freedom to propose changes because resources have not been allocated toward integrating and testing the proposed changes. We allocate these resources with [[Scheduled software release process#Contracts|release contracts]]. At this milestone, we will ask that all major new features and packages or large pieces of code be identified.

==== Steam Milestone Announcement ====
The announcement of meeting this Milestone will include: <br>
* A list of all Release Contracts currently confirmed and those under consideration. The deadline for confirming Release Contracts and new features will be set for the Water Milestone which will come 30 days after Steam.
* A list of packages targeted for the Release and the package maintainers.
* A link to the wiki page where the release status be maintained
* The name and link to the branch which will become the build candidate


=== '''Water Milestone''' ===
=== Build number ===
At the Water Milestone all new features should be identified and a first implementation should be in the candidate build by this milestone. The purpose of the Water Milestone is to help ensure that changes have adequate time to be tested and to shift focus to bug-fixing for the final release. Development builds of packages can continue, however they will not be included in the release image unless you request a break of the Water Milestone (see below).


Each release stream is composed of a series of builds: a number of development builds, followed by some release candidates, followed by a final build that consists of the official, final release. Each build has a unique number. As of 2012, the numbering scheme works as follows:
By the beginning start of Water, developers are expected to have created release contracts for each desired change.


Each Major Release resets build numbering to start at 1 for the first development build. Later builds will increment that number, starting with development builds. When stabilising, release candidates will continue the increment-by-one pattern until the final build is reached. For example, here is a hypothetical situation:
On or before the Water Milestone, Module maintainers should propose a set of bug fixes to get into the testing 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 Release Candidate build. After this date no changes are allowed in to the code without the approval of the module maintainer and the [[Unscheduled_software_release_process#Triage_Team|Release Triage team]].


* 12.1.0 enters development. The first build is build 1. Builds 2,3,4,5,...34 are produced during the development phase.
==== Water Milestone Announcement ====
* 12.1.0 enters final stabilisation. Builds 35, 36, 37 are published as release candidates.
The announcement of meeting this Milestone will include: <br>
* The 12.1.0 release is finished. 12.1.0 build 37 is published as the official, final version.
* A list of all Release Contracts and target features for the release.
* 12.2.0 enters development. Build numbering resets to build 1. Development builds 1,2,3,4,...,25 are produced
* The set of bug fixes currently marked as blocker for the release and the way to query for the blockers in Trac.
* 12.2.0 enters final stabilisation. Builds 26,27,28 are published as release candidates.
* The current candidate build and a description of its reliability and important known, open bugs.
* The 12.2.0 release is finished. 12.2.0 build 28 is published as the official, final version.


=== Build filenames ===
==== Water Milestone Exception Procedure ====
If you think that you need to add a feature after the Water Milestone, then you should ask for approval. To do so, send an email to devel@lists.laptop.org and localization@lists.laptop.org with the following information.


As of 2012, the filenames of the release files produced by the [[build system]] are structured in the following manner:
* A description of what you want to change
* Rationale for why the change is important enough to be allowed in after the Water Milestone.
* Impact of *not* accepting the development at this point of the schedule.
* Information on what testing you've already done on the development to help reduce the risk.


# Fourth digit of the four-digit year corresponding to the Major Release (the "Y" component above), e.g. "2" in 2012, "3" in 2013
After passing ''Water Milestone'', changes requiring reallocation of integration and test resources (i.e. requiring a new release contract) will require approval by module maintainers and Release Management before being accepted.
# The release number within the current year (first or second release, the "H" component from above). For 12.2.0, thats "2".
# Three-digit zero-padded build number, e.g. 098
# An alphabetic 'deployment identifier', max 2 characters. OLPC will use "o", deployments may wish to use their two-letter country code.
# A numeric code identifying the target laptop model.
# A '.'
# The file extension


The laptop model codes are:
The release team will evaluate the request and provide feedback.
* XO-1: 0
* XO-1.5: 1
* XO-1.75: 2
* XO-3: 3
* XO-4: 4


For example, 21099o1.img is 12.1.x build 99 for XO-1.5 published by OLPC. 22031ni2.img is 12.2.0 build 31 for XO-1.5, for the OLPC Nicaragua project.
Approval will come in the form of +1's. Two +1's (without any negative feedback) and approval from the Release Team are necessary to build. If there is negative feedback, conversation will ensue and a new vote will be issued.


If the deployment identifier code is limited to 2 characters, the resultant filename will adhere to the 8.3 limit (8 character filename, 3 character extension). This is the maximum filename length that can be read by the firmware when using VFAT-formatted USB media (this is common). This is why it is strongly recommended to limit the deployment identifier to two characters, although the build system does let you use more.
==== String Freeze ====
All strings which need translation should be finalized by this time. This should allow the translation teams to start final translation per [http://wiki.laptop.org/go/Localization/Workflow their process].


== Supported locales/languages ==
Minor changes (e.g. bug fixes) can still be added without approval until the transition to Ice. Changes requiring great coordination to deliver like string changes and UI changes will be deferred if possible.


In the interest of keeping the image size down, OLPC only ships certain locales/translations in its released builds. New locales can be requested by writing to the devel [[mailing lists|mailing list]]. The criteria that must be met are:
=== Ice Milestone ===
* There is an active or soon-upcoming deployment (of any size) that is expected to use this language in the software release being targetted.
As of this date every single change to the source code needs to be approved by the
* The development cycle for the targetted software release is at an appropriate point (i.e. open-development, not frozen) to accept changes of this scope
[[Unscheduled_software_release_process#Release_Team|Release Team]] before it happens.


On one hand, the selection of locales included in OLPC's official builds is somewhat irrelevant, because we expect all significant deployments to use the [[build system]] to produce a customized version of each official release that they ship; the supported locales can be modified at this time.
Only bug fixes marked as blocker should be allowed in the image after this Milestone.


On the other hand, deployments should aim to become actively involved in the OLPC release process: updating, testing and refining their translations during the development stages of the release. This can't be done if OLPC's own releases don't include the locales/translations in question; asking deployments to regularly re-spin development builds is probably asking a bit much. So, deployments requesting inclusion of their specific locale makes a lot of sense, even if they will re-spin and customize the official release build when the time comes.
The Release Team will review all bugs marked as blockers and re-triage them as necessary.


== How to contribute ==
All translation packages should be final by this time. <br>


=== Developing ===
If you think you need to add bug fix after the Ice Milestone you must follow the same process as defined in the Water Milestone above.
=== Testing ===


=== Final Test Milestone ===
=== Translation ===
This is when the count down to release starts. The release is not final until the [[Unscheduled_software_release_process#Release_Team|Release Team]] signs off and the [[USR_Checklist|Release Process Checklist]] is complete. At this stage, quality is the only thing which will delay the release date.


Translation of the Sugar user interface (UI) is primarily handled via the Pootle instance hosted by Sugar Labs on behalf of the broader Sugar Labs / OLPC / eToys communities.
=== Announcement Day Milestone ===
This is the target release day but it is not the actual release day until the Release Team signs off and the Release Process Checklist is complete.


http://translate.sugarlabs.org/
= Release Steps =
Minor Releases follow the process outline here: <br>
http://wiki.laptop.org/go/Software_ECO_process


Documentation about the Translation Team and their processes can be found here:
In particular a Release must complete the checklist: <br>
http://wiki.laptop.org/go/USR_Checklist


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


The Translation Team coordinates it's efforts via the Localization (L10n) list hosted on OLPC's Mailman instance:
= Release Goals and Request Prioritization =


http://lists.laptop.org/listinfo/localization
TBD.


Translation of the GNOME boot UI strings in OLPC Sugar / GNOME dual-boot images occurs in various upstream locations: the [http://l10n.gnome.org/releases/olpc/ GNOME L10n server], the Fedora Transifex server, and the Translation Project. Specific upstream packages used by OLPC are [http://translate.sugarlabs.org/projects/upstream_l10n/ tracked] on Pootle and several upstream packages are collaboratively localized and hosted on Pootle [http://translate.sugarlabs.org/projects/upstream_POT/ (e.g. AbiWord and Gnash)].
Existing thinking on the current plan is here <br>
http://wiki.laptop.org/go/Plan_of_Record-2008/Draft_3


= Open Items =
== See also ==


* [[Release Process Home/Historical]] - historical plans for parts of the release process
Open items needing definition and additional work
* Finalize Major Release process details and create page for it
* Update and post a new picture of the release process and release trains
* Create a schedule for 9.1.0 and perhaps 8.2.1
* List the software components, maintainers and modules in a release.
* Create an activities development process including a way to put them in releases.
* Make it easy to find the source for any component and build.
* Define feature and bug prioritization process
* Define release quality metrics and include test details and milestones
* Create governance and community best practices guidelines
* Gather community buy in and get consensus
* Finalize release and triage team members
* Review and finalize [http://wiki.laptop.org/go/Releases Status page]
* Put the process in to practice, revise and improve
* Include more details on translations in the process


[[Category:Releases]]
[[User:CScott]]'s suggestions for further discussion:
* Is the "product" of our release a core OS, an OS plus "reference" activities, or are we ultimately responsible for producing final configurations for every deployment? Assuming that it's the second, what's the release process/schedule for those activities, and who decides (a) what activities are considered for inclusion, (b) what bugs will disqualify an activity for inclusion, and (c) what activities we will not "release" without? At what point(s) do we hand off release candidates for countries to validate against their activity set?
* [http://www.us.debian.org/doc/developers-reference/ch-resources.en.html#s-codenames Debian suggests using code names pre-release] so that end users aren't confused by the presence of unreleased builds on a stream with "8.2" in the name. In the past we had builds appearing on the "update.1" stream before we officially released "update.1"; we should consider altering that practice. [http://fedoraproject.org/wiki/ReleaseEngineering/Overview Fedora allows the community to vote on the codename for each release] which seems reasonable.
* Fedora is currently on a [http://fedoraproject.org/wiki/Releases/Schedule 6-month release schedule]. It has been suggested that we attempt to synchronize with them, and release roughly a month after Fedora does.
* We probably need to add process steps to handle [http://fedoraproject.org/wiki/ReleaseEngineering/Overview#Export_Approval export approval].
* Is six months too long between major releases for a stack in heavy active development? The longer the cycle, the more churn occurs and the harder it seems to be to stabilize. A four-month or even three-month release schedule could still sync up with Fedora, and might avoid the need to spend additional engineering effort on non-trivial minor releases. How will we know whether our release cycles are the right length? (Mozilla started with a 5 week milestone cycle, and [http://www.mozilla.org/roadmap/roadmap-05-Jun-2002.html#tree-management moved to quarterly milestones]; Fedora, Gnome, and Ubuntu are on 6-month cycles.)
* I believe it is worth adopting a [http://live.gnome.org/RoadMap community roadmap] like GNOME where, at the start of the release cycle, component owners can outline what they hope to land in the next major release.

Latest revision as of 04:32, 19 December 2013

  For Developers
  english | español HowTo [ID# 294137]  +/-  

This page describes OLPC's software release process.

Goals

The goals of the release process process are to:

  1. Ensure high quality releases which meet the needs of users in a timely fashion.
  2. Maximize the participation, productivity and enthusiasm of the open source community.
  3. Create a predictable process which helps users and developers plan for the future.

The output

The output of this process is a generic software image suitable for installation on OLPC's XO laptop platform. The image is generic in the sense that it includes a rounded selection of activities, applications, and languages.

We do not expect established deployments to use this software image directly. Almost all deployments have needs or desires to customise the software image that they ship (e.g. with new languages, a different selection of activities, specific default settings, etc.). We expect that most established deployments will use the Build system to produce a variant of the release including their own customizations.

Nevertheless, the process of developing and stabilising the generic release is key, as it forms the base of all the deployment-customized software releases.

The process

Each release is planned in advance, and this process results in a slightly different development/release methodology for each release. However, certain guidelines and well-established principles are stuck to:

  • The release planning documentation is made public from the start.
  • Release development is divided into individual stages, separated by milestones (discussed below)
  • Releases are coordinated according to a schedule of milestones, which is decided early on, and included in the release plan.
    • This is important so that our customers know when to expect the final release, when they should get involved with development and testing, and to allow them to plan their upgrade/rollout.
    • This is also a well-established practice in our neighbouring open source communities
  • The release schedule is honored strictly. That is, the milestone dates are adhered to, even if some sacrifices (such as exclusion of planned features which didn't arrive in time) are made. Some flexibility can be allowed for, but these should be exceptional cases only.

The development process is divided into distinct stages, with milestones to mark the progression from each one to another. Each of the items below links to an extensive explanation (including technical and managerial procedures) of each stage, be sure to read them all if you want to become involved in the release process.

  1. Release Process/Planning
  2. Release Process/Development
  3. Release Process/Stabilization
  4. Release Process/Release

Major and minor releases

Major releases include large platform changes (such as updating to the latest versions of Fedora & Linux) and addition of new features.

Minor releases (a.k.a. point releases) are limited to the fixing of bugs which are affecting deployments, and occasionally include translation and locale updates (requested by deployments).

This was previously adhered to quite strictly, but the recent minor releases in the 10.1 series have seriously blurred the lines between major and minor releases. This degrade of practice started when OLPC's development resources were downsized, meaning that there were no resources in sight to allow for a future major release, resulting in the relaxing of criteria on what could go into the minor release. However, now that OLPC's software team has grown a bit again, it is my hope that this previous practice can be restored, so I've documented it that way. Time will tell... -DanielDrake 17:22, 9 February 2011 (UTC)

Features

New major releases will include a set of new features, pioneered and developed by OLPC staff and community members. A feature is defined as a significant change or enhancement to the current version of XO software that may or may not include new packages. Our feature process should be driven by the needs and feedback of our customers (deployments) and our users (young children).

Features are usually considered to meet one or more of the following objectives:

  1. Highly user visible changes
  2. Improvements or changes that require non-trivial cross-package integration
  3. Noteworthy enough to call out in the release notes
  4. Exciting new capabilities we can trumpet.

Some examples might include:

  • New educational tools that will be used by children
  • New features from upstream that we are making available on the XO for the first time
  • Improvements to tools and infrastructure used by activity developers

OLPC plans which features to develop for each release according to its key principles and based on feedback from customers. During planning stages, a discussion will usually be started on the devel mailing list in order to solicit input from the community, and to clearly communicate that the feature planning process is underway.

Features can also enter releases through upstream projects. For example, a new feature added to GNOME will automatically enter an OLPC release once a release is made including that specific GNOME version. Some of these features may have direct impact on OLPC and are good candidates to be discussed in the release notes.

Features outside of OLPC's feature plan are also welcome to be contributed by interested individuals and deployments, providing that they meet the normal code acceptance criteria (open source, good code quality, good documentation, appointed maintainer, ...), and provided that they are accepted and included within the acceptable stages of the release schedule. In many cases, development of such features does not belong at the OLPC level, but rather in the upstream projects (for example, development of a new Sugar feature would fall entirely within the SugarLabs community, and would not need acceptance or review by OLPC).

Maintainability and sustainability

OLPC has historically made quite a few changes to standard open source software technologies (Linux, Fedora, etc) and this hurts us in every release cycle. We are now a small team and every release cycle we spend a lot of time bringing forward the the collection of OLPC-local changes.

In recent times, this "delta" from upstream software has been greatly reduced. We need to keep working in that direction, which means strict controls on any new non-upstream changes being added. The most effective way to approach this is to get your changes upstream first.

Version numbering

Release names

The release names are of the form "Y.H.NN"

  • Y = target calendar year
  • H = major release number representing first release or second release of the calendar year
  • NN represents the Minor Release, starting with .0 at the availability of the first Major Release and going up by 1 for each publicly available minor release after that.

A Major Release and all its derivative Minor Releases can be referred to with a variable (or wildcard) in the third digit (e.g. 8.2.x refers to 8.2.0, 8.2.1 and 8.2.3).

Examples:

  • 8.1.1: First Minor Release rebuild based on the first Major Release in 2008
  • 8.2.0: Second Major Release in 2008

Build number

Each release stream is composed of a series of builds: a number of development builds, followed by some release candidates, followed by a final build that consists of the official, final release. Each build has a unique number. As of 2012, the numbering scheme works as follows:

Each Major Release resets build numbering to start at 1 for the first development build. Later builds will increment that number, starting with development builds. When stabilising, release candidates will continue the increment-by-one pattern until the final build is reached. For example, here is a hypothetical situation:

  • 12.1.0 enters development. The first build is build 1. Builds 2,3,4,5,...34 are produced during the development phase.
  • 12.1.0 enters final stabilisation. Builds 35, 36, 37 are published as release candidates.
  • The 12.1.0 release is finished. 12.1.0 build 37 is published as the official, final version.
  • 12.2.0 enters development. Build numbering resets to build 1. Development builds 1,2,3,4,...,25 are produced
  • 12.2.0 enters final stabilisation. Builds 26,27,28 are published as release candidates.
  • The 12.2.0 release is finished. 12.2.0 build 28 is published as the official, final version.

Build filenames

As of 2012, the filenames of the release files produced by the build system are structured in the following manner:

  1. Fourth digit of the four-digit year corresponding to the Major Release (the "Y" component above), e.g. "2" in 2012, "3" in 2013
  2. The release number within the current year (first or second release, the "H" component from above). For 12.2.0, thats "2".
  3. Three-digit zero-padded build number, e.g. 098
  4. An alphabetic 'deployment identifier', max 2 characters. OLPC will use "o", deployments may wish to use their two-letter country code.
  5. A numeric code identifying the target laptop model.
  6. A '.'
  7. The file extension

The laptop model codes are:

  • XO-1: 0
  • XO-1.5: 1
  • XO-1.75: 2
  • XO-3: 3
  • XO-4: 4

For example, 21099o1.img is 12.1.x build 99 for XO-1.5 published by OLPC. 22031ni2.img is 12.2.0 build 31 for XO-1.5, for the OLPC Nicaragua project.

If the deployment identifier code is limited to 2 characters, the resultant filename will adhere to the 8.3 limit (8 character filename, 3 character extension). This is the maximum filename length that can be read by the firmware when using VFAT-formatted USB media (this is common). This is why it is strongly recommended to limit the deployment identifier to two characters, although the build system does let you use more.

Supported locales/languages

In the interest of keeping the image size down, OLPC only ships certain locales/translations in its released builds. New locales can be requested by writing to the devel mailing list. The criteria that must be met are:

  • There is an active or soon-upcoming deployment (of any size) that is expected to use this language in the software release being targetted.
  • The development cycle for the targetted software release is at an appropriate point (i.e. open-development, not frozen) to accept changes of this scope

On one hand, the selection of locales included in OLPC's official builds is somewhat irrelevant, because we expect all significant deployments to use the build system to produce a customized version of each official release that they ship; the supported locales can be modified at this time.

On the other hand, deployments should aim to become actively involved in the OLPC release process: updating, testing and refining their translations during the development stages of the release. This can't be done if OLPC's own releases don't include the locales/translations in question; asking deployments to regularly re-spin development builds is probably asking a bit much. So, deployments requesting inclusion of their specific locale makes a lot of sense, even if they will re-spin and customize the official release build when the time comes.

How to contribute

Developing

Testing

Translation

Translation of the Sugar user interface (UI) is primarily handled via the Pootle instance hosted by Sugar Labs on behalf of the broader Sugar Labs / OLPC / eToys communities.

http://translate.sugarlabs.org/

Documentation about the Translation Team and their processes can be found here:

http://wiki.sugarlabs.org/go/Translation_Team

The Translation Team coordinates it's efforts via the Localization (L10n) list hosted on OLPC's Mailman instance:

http://lists.laptop.org/listinfo/localization

Translation of the GNOME boot UI strings in OLPC Sugar / GNOME dual-boot images occurs in various upstream locations: the GNOME L10n server, the Fedora Transifex server, and the Translation Project. Specific upstream packages used by OLPC are tracked on Pootle and several upstream packages are collaboratively localized and hosted on Pootle (e.g. AbiWord and Gnash).

See also

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Release_Process&oldid=294137"