Talk:Release Process

Comments

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)