Talk:Release Process

From OLPC
Jump to navigation Jump to search

Comments:

Comments from Scott on open items

My resolution inline below:

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?

GS - Added as an open questions section.

  • Fedora is currently on a 6-month release schedule. It has been suggested that we attempt to synchronize with them, and release roughly a month after Fedora does.
  • 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 moved to quarterly milestones; Fedora, Gnome, and Ubuntu are on 6-month cycles.)
    Major releases every 6 months with a planned minor release every 3 months (in addition to emergency/unplanned updates and minor releases) sounds good to me. 41.234.178.241 04:32, 15 July 2008 (UTC)

GS - left all dates in place pending further comment or consensus. So these comments were not addressed. If they get agreement, I'm fine with any of them.

Comment on roadmap definition section

Comment from Scott:

  • I believe it is worth adopting a 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.

Integrated as: Part of the process should be like Gnome's where they gather input from the community by working with component owners.

Comment on need to include activities in build name section

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. --CScott 02:15, 29 June 2008 (UTC)


Comment on one good example of build type definition

I think this was from Scott, but not sureGregorio 14:47, 18 July 2008 (UTC)

Debian descriptions of stable/testing/unstable/experimental.

Exception Process Comment from Scott

We probably need to add process steps to handle export approval.

I believe that this is addressed in the Water Milestone

Comment on release code names

Comments on Minor Release Section

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

Example names of Minor Releases names are 8.1.1, 8.1.2, 8.2.1, 8.2.2

I think we could benefit from trying to define the scope of minor releases more closely. If we release twice a year and support for a year, there will be a newer released major version for half the support window of the old release. How much time do we expect to spend backporting new features and refixing fixed bugs?

Gregorio 13:49, 11 July 2008 (UTC) See "Meaning of Support and Support Time Frame sections for response to this question.

For reference here is Debian's criteria for updates to stable: basically only "critical" bugs, where critical is defined as "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." Fedora uses a more liberal policy: basically any proposed update which has not been voted down by testers after a week goes into a rolling "minor release". We should decide on an aim point between these extremes: are we "default yes" or "default no" on making minor releases? How many users must be affected before we'll consider one? My personal feeling is that minor releases suck away scarse release manager, QA, and engineering time, and thus should be avoided absent compelling reason, but I know that others feel we should make frequent minor releases with whatever is "easy" to backport, to help ensure that we make fixes and features available as quickly as possible to our users. --CScott 02:02, 29 June 2008 (UTC)

I agree with cscott. The better our definition that minor releases are for 'critical bug fixes' the more likely we will only have to do 1-3 minor releases, and generally only within the first 2-3 months of a major release. We should have some examples of what that means. The example above - support for new languages is a good example; and we can generally push a lot of the testing back to the country since that is in the deployment guide (they translate and test). An example related to a security issue should be evaluated for how likely it is; how many people it would affect; how much disruption the fix causes to the rest of the code base, etc.Kimquirk 18:44, 29 June 2008 (UTC)

Comment on Release Names

Addressed in latest text Gregorio 13:37, 11 July 2008 (UTC)

Example names of Major Releases are 8.1.0, 8.2.0, 9.1.0, 9.2.0

Is it worth dropping the .0 suffix for the first release? This seems to be the practice for Gnome (2.22), Ubuntu (8.04), and Fedora (Fedora 9). --CScott 01:31, 29 June 2008 (UTC)


Comments on Meaning of Support

Addressed in the updated content Gregorio 13:26, 11 July 2008 (UTC)

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, which usually drive the dates for minor releases. And, support means upgradability and backward compatibility. The matrix of test scenarios to ensure these two items is what limits how many release we can support at any given time. Each 'supported' release must be able to upgrade to the next one; and each 'supported' release must provide backward compatibility with any other 'supported' release. We have a lot to talk about here as this implies that every release has an upgrade feature and a backward compatibility feature that needs discussion, design, development, and lots of testing Kimquirk 18:37, 29 June 2008 (UTC)

A set of Non-Upward-Compatible (NUC) features will inevitably creep into any release. If you aren't paying attention, you won't realize they are NUC's until you are already tasked with supporting them -- way too late. Avoiding this trap will require a solid understanding of the release content well before the content is released. This speaks to the critical need for requirements definition and planning, as well as a plan of record identifying the features for a release. Doing this also has benefits for the 'support discussion' as it allows one to understand the level of support required before declaring a certain release as log term or patch fix.

So we also need to talk about patching current features and bug fixes back to prior releases? Steve Holton Tue Jul 8 13:39:30 EDT 2008

Comments on support time frame

Addressed in the latest version Gregorio 13:13, 11 July 2008 (UTC) Each Major Release will be supported for a period of 1 year from the time the Release Process Checklist is complete. The date in the "Release team final sign off" field defines the start of the 1 year support time frame.

Scott suggested that we could be well served by choosing which releases to support long-term only after having deployed them. That way, we will have much harder data with which to judge their quality. Is this approach feasible? --Michael Stone 17:41, 28 June 2008 (UTC)

I don't think this is feasible as a customer needs to know way ahead of time whether a release is going to be supported. We need to be able to support major releases, or don't call it a major release. So I would prefer to say we are going to support the current and 1 previous major release, rather than say we are going to support a release for 1 year. That way if there is a good reason to delay a major release, or to go to a new process with many more major releases/year, then support is defined by the release (which we understand because we tested it) rather than by some arbitrary time period.Kimquirk 18:37, 29 June 2008 (UTC)

An alternate suggestion: we might plan to alternate "big" and "little" major releases, with the first release of the year planned for aggressive new features, and the second for stability and upstream maintenance work. The "little" releases would be candidates for longer-term support, say 2 or 3 years. I don't know if I'd actually advocate this, since we are trying to integrate lots of pieces with their own feature "bigness" schedules, but I thought I'd mention the idea. --CScott 01:31, 29 June 2008 (UTC)

Translation Schedule Suggestions from Korakurider

>From translator's point of view, things will go like this:

a. Developers generate updated POT and commit it to repo. Then the change will be automatically merged to PO on Pootle.

b. Translators enter or edit translations on Pootle. then test it with the latest software.

c. Admins for language/project of Pootle commit translations to repo when they are comfortable with the translations.

d. Developers build their package and the latest translations in repo will be pulled.

e. Repeat from a or b.

There are several important events for each development cycle:

a) "String freeze" POT is friezed and translators enjoy translation without caring of string change.

If developers want to change string/POT after that, prior communication would be needed.

b) "Translation refresh" When committed translations in repo will be pulled into package build.

It's ok if every build use the latest in repo. But if not, the milestone needs to be scheduled.

c) "Translation freeze" Developers and testers might want to control it, while I 'm not sure whether this is needed actually:

+ I think commit from Pootle is done to trunk of repo (Update.1 Project on Pootle would be exception). But developer want to make branch for the specific release.

+ Set translation deadline for extensive testing of release candidate.

Translators could easily manage their work if these milestones are scheduled in project plan for each release cycle. (see http://lists.laptop.org/pipermail/localization/2007-December/000220.html)

General

Comment from Scott (I believe, please correct as needed) directed at the milestones section http://wiki.laptop.org/go/Release_Process_Home#Milestones that we should adopt the Fedora milestones essentially verbtaim:
http://fedoraproject.org/wiki/ReleaseEngineering/Overview#Freezes_and_Pre-Releases
http://fedoraproject.org/wiki/Releases/HistoricalSchedules
Gregorio 03:31, 3 July 2008 (UTC)

Comment on :I would recommend that the 'H' doesn't tie to a time of year at all, but just whether this is the first, second, or possibly third major release in the year. This gives us the flexibility in the future of changing the release cycle.Kimquirk 18:46, 29 June 2008 (UTC)

  • NN = minor release number

Gregorio 00:36, 1 July 2008 (UTC) Addressed in section http://wiki.laptop.org/go/Release_Process_Home#Release_Names. It now says two releases a year without reference to first half/second half

I removed this comment per Scott's suggestion. Gregorio 14:27, 1 July 2008 (UTC) At the discretion of the Release Team, the build may or may not contain activities.

I strongly object to this last sentence, which reopens trac #2064 and is a technical decision entirely inappropriate for a release planning document. --CScott 02:28, 29 June 2008 (UTC)
Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Talk:Release_Process&oldid=252872"