Release Process/Historical
For information on current release processes, see Release Process Home
This page details historical plans for the software release process, which may be useful for future planning.
|
The currency of this article or section may be limited by out-of-date information. There may be relevant discussion on its talk page |
Release Goals and Request Prioritization
Some thoughts from Michael Stone: Plan_of_Record-2008/Draft_3
ECO Process
The formal ECO process, now replaced by a less formal system made possible through a smaller development team, is documented at Software ECO process and USR Checklist
Support
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 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 Release Process Checklist.
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.
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).
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
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).
April Fools Release Schedule
An April Fools joke by Charles Merriam (http://lists.laptop.org/pipermail/devel/2008-April/012318.html) inspired the following (serious) proposal, which was never put into practice:
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
- 95 days before target date Announce Steam Milestone coming in 5 Days. .
- 90 days before target date Announce Steam Milestone achieved. Steam level Release Candidate Finalized
- 65 days before target date Announce Water Milestone coming in 5 days. Water level Release Candidate chosen
- 60 days before target date Announce Water Milestone achieved. Water level Release Candidate finalized
- 35 days before target date Announce Ice Milestone coming in 5 days.
- 30 days before target date Announce Ice Milestone achieved.
- 15 days before target date Announce Final Test starting in 5 days
- 10 days before target date Announce start of Final Test
- When Final Test Passes Announcement Day.
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 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:
- 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 will be maintained
- The name and link to the branch which will become the build candidate
Water Milestone
At the Water Milestone all new features should be identified and a first implementation should be in the candidate build. The purpose of the Water Milestone is to 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 an exception to the Water Milestone (see below).
At the announcement of the Water Milestone developers are expected to have created release contracts for each new feature or major change.
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.
Minor changes (e.g. bug fixes) can still be added without approval until the transition the Ice Milestone. Changes requiring great coordination to deliver like string changes and UI changes will be deferred if possible.
After the Water Milestone significant code changes should get approval of the module maintainer. As the Ice Milestone approaches, the module maintainers and overall release maintainer will become more discriminating in which changes they will accept.
Water Milestone Announcement
The announcement of meeting this Milestone will include:
- A list of all Release Contracts and target features for the release.
- The set of bug fixes currently marked as blocker for the release and the way to query for the blockers in Trac.
- The current candidate build and a description of its reliability and important open bugs.
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.
- 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.
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 team will evaluate the request and provide feedback.
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.
String Freeze
All strings which need translation should be finalized by Water Milestone. This allows translation teams to start final translation per their process.
POT is frozen at the Water Milestone and translators begin translating with the assumption that there will be no more string changes. If developers want to change string/POT after the Water Milestone, prior approval will be needed from the Localization list: localization@lists.laptop.org
Ice Milestone
As of this date every single change to the source code needs to be approved by the Release Team before it happens.
Only bug fixes marked as blocker should be allowed in the image after this Milestone. The Release Team will review all bugs marked as blockers and re-triage them as necessary.
All translation packages should be final by this time.
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.
Translation Refresh
It's ok if every build uses the latest translations in repo (link or definition?). But if not, the committed translations in repo must be pulled into package builds by the Ice Milestone.
Final Test Milestone
This is when the count down to release starts. The release is not final until the Release Team signs off and the Release Process Checklist is complete. At this stage, quality is the only thing which will delay the release date.
All test plans should be defined and posted prior to the Final Test Milestone
Final Test Announcement
The announcement of meeting this Milestone will include:
- The name of the Release Candidate build
- A request for all testers to report results and give +1 or -1 on Release Candidate being released
- The results of testing so far and a link to known open bugs in Trac
- A list of priority areas that need additional testing
Translation Freeze
Commit from Pootle is done. All translations are final.
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 completed Release Process Checklist. Once signed off the Release Process Checklist is finalized and posted, Kim sends announcement e-mail approving release availability
Open Items
Open items needing definition and additional work
- Update and post a new picture of the release process and release trains
- 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
- Put the process in to practice, revise and improve!
Open questions:
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?