Talk:Release Process

Comments:

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)