*Icehouse release schedule & coordination vacation planning

This session will include the following subject(s):

Icehouse release schedule & coordination:

In  this session we'll discuss and decide the deadlines and milestones for  the Icehouse coordinated release cycle. We'll also discuss potential  changes in the process, the format of the weekly release status meeting,  and the improvements needed to the toolset supporting the release  management tasks.

(Session proposed by Thierry Carrez)

Considering translation in release cycle:

In  Havana release, I18n team worked together with Horizon team to complete  12 languages translation (1700+ strings) and run the translation  verification test ( reported 15+ bugs related with I18n) within 1 month  from string frozen date to RC2. In Icehouse release, we are going to  cover more components, that means, more strings need to be translated. 1  month may be not enough. 
 
We need to find a way to give  translators enough time for translation and verification test. We can  discuss this in this session.

(Session proposed by Ying Chun Guo)

------------------------------------------------------------------------------------------------------------------------

Release schedule
	* Release date
		* Next summit on the week of May 12 (including Design Summit ?)
		* Release on May 1st: too late for "6-month", only one week between release and summit
		* Release on April 24: just after Easter weekend
		* Consensus: Release on April 17: three full weeks between release and summit
			* should one of those three weeks be "officially off" ?
			* Anticipating future separated design summits ?
	* Post-FF duration
		* 6 weeks (like for Havana)
		* 7 weeks to give more time for RCs ?
	* Chosen option is line 2 of the PDF (6 weeks with 7 weeks for XMas break milestone)

Everyone is invited to Thierry's ski vacation on the 13th of March.
Ski resort is La Plagne (Les Coches, French Alps)

Release cycle and coordination
	* Freezes
		* Dependency freeze ? Is it enforceable ? Enforced using requirements repo reviews
		* Generalizing FeatureProposalFreeze on a common date ?
		* RC dance: when ready, or date-based ? -> when ready, with a hint
		* Move feature freeze to the Wednesday ? Tuesday as a safety valve
	* Coordination with Docs & Translations
		* Importing all languages, or only importing languages with good quality?
			* Would be good to have the ability to filter incomplete/crappy sets
		* Continously importing translations, or importing at certain time points?
			* Figure out how to test with some key translations enabled
			* Continue to continously import, consider having just one +2 for this
		* Need a clear communication about when are RCs and whether translations are accepted for RCs
			* Have a translations status checkpoint at weekly release meeting during RC dance period
		* Earlier string freeze ? no
		* Handling stringfreeze exceptions ?
			* try to detect when string freeze is accidentally broken
			* work on a more defined process to warn the translations team in case of intentional breakage
				* perhaps StringFreezeImpact --> emails openstack-i18n@lists

Weekly meeting format
	* Challenges
		* Scaling up
		* Most of the meeting time is spent doing per-project status sync that could be done separately
		* #openstack-relmgr-office, logged
		* Not used to raise cross-project priorities and issues that much
	* New meeting format
		* Program status -- should we use another forum for that ?
		* Per-project status sync: schedule weekly individual release sync points (could be same time as project meeting or not)
		* Only have the weekly status meeting when specific issues are raised (decision on Tuesday european morning)
		* Could be quick ? yes
		* Name for that meeting ? tbd

Release process & tooling
	* Missing automation: Gerrit branch creation/deletion
	* Need for 2-day milestone-proposed branches for project milestones ?
		* Milestones are point in time more than "releases"
		* 9 changes backported over the havana cycle
		* Replace with a "proposed" tag and a soft freeze ?
			* just tag an old commit on Thursday, create MP only in case of need
	* "Naming" milestone-proposed to avoid reusing branch names ?
	* Release manager: a team of 2+ ? yes
	* We must also start testing that clients as released (rather than tip of master) work with the released servers