Talk:Release Process

Comments:

Comment on Release Names

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)