Jump to: navigation, search

Difference between revisions of "StringFreeze"

(→‎What changes are not affected by the string freeze?)
(reverting to the version written by dolph in march 2014)
Line 1: Line 1:
−
=== What does string freeze means? ===
+
=== (Soft) String Freeze ===
  
−
String freeze means that '''we cannot add new strings''' but we could be able to '''improve strings and fix bugs'''. It could be considered as a '''soft freeze'''.
+
String Freeze usually happens at the same time as Feature Freeze.
  
−
=== Why is there a string freeze? ===
+
Once SF kicks in, you are no longer allowed to accept proposed changes containing modifications in user-facing strings. Such changes should be rejected by the review team and postponed until the next series development opens (which should happen when RC1 is published).
  
−
The string freeze ensures that documentation and translation teams have a relatively-stable universe to produce documentation and translations for.
+
What's OK:
 +
* Adding/changing log messages
 +
* Adding a missing description to a config option
  
−
=== When does the string freeze happens? ===
 
  
−
The string freeze happens at the same time as [[FeatureFreeze|feature freeze]].
+
What's not OK:
 +
* Changing a user-visible API error message
 +
* Changing a config option name or existing description
  
−
=== How long is there a string freeze? ===
+
=== Hard String Freeze ===
  
−
The string freeze is maintained for every module affected by the freeze until the release branch is cut. When that happens, the string freeze is lifted from master.
+
This happens usually when RC1 is tagged.
  
−
=== What changes are affected by the string freeze? ===
+
At this point, ideally no strings are changed, to give translator time to finish up their efforts. Ideally at least 10 working days later, another release will be made to include all the extra translated strings since the hard Freeze.
  
−
Once the string freeze kicks in, proposed changes containing large modifications in user-facing strings cannot be accepted. In other words, additions or significant changes in strings marked for translation in a module included in OpenStack core is affected by the freeze. E.g.:
+
=== Rationale ===
  
−
* Change a user-visible API error message
+
SF ensures that the documentation and translation teams have a relatively-stable universe to produce documentation and translations for.
−
* Change a config option name or existing description
 
−
* Change a translatable log message that is modifying the meaning or the context of the message
 
  
 +
Its annoying to update a string just after its been translated. Adding an extra string to translate is less frustrating for them.
  
−
Such changes should be rejected by the review team and postponed until the next series development opens - which should happen when RC1 is published.
+
For log messages, its better to have an untranslated log message, rather than a hidden error condition.
  
−
=== What changes are not affected by the string freeze? ===
+
=== Exception procedure ===
  
−
Proposed changes that do not contain modifications affecting user-facing strings won't be affected by the string freeze. E.g.:
+
If you want to propose a change containing a user-facing string modification (that you believe fixes an important issue) for merging into the release under development after SF, follow those steps:
−
 
 
−
* Add, remove or change of a message that is not marked for translation.
 
−
* Add a missing description to a config option
 
−
* Add or change of log messages that are not translated (eg. debug logs).
 
−
* Add a translatable string identical to an existing message that is already marked for translation and has the same meaning and context. The available translation will be re-used automatically.
 
−
 
 
−
=== What should I do in case I want to break the string freeze? ===
 
−
 
 
−
We need to make a difference between small and medium/large changes and if the change is proposed during the RC or after the RC release - most of translation teams will complete their translations before RC is shipped.
 
−
 
 
−
This distinction is neccesary because we need to maintain a balance of when the translation deadline is and how many new strings are added (generally around 5 string addition/changes). As long as fairly small features land in early RC cycle adding a few '''words''' can be accepted.
 
−
 
 
−
 
 
−
==== Small changes during the RC period ====
 
−
 
 
−
We will allow modifications during the RC period for the following scenarios:
 
−
 
 
−
* A string is misunderstanding and should be updated.
 
−
* A string should be translated yet not marked with _().
 
−
 
 
−
 
 
−
==== Medium/Large changes and changes after the RC release ====
 
−
 
 
−
If you want to propose a '''large change during the RC period''' or a '''change in general after the RC release''' containing a user-facing string modification (that you believe fixes an important issue) for merging into the release under development after string freeze, follow those steps:
 
  
 
* Mention the need for a string freeze exception on the review
 
* Mention the need for a string freeze exception on the review
Line 58: Line 36:
 
* Raise a thread to discuss the proposed change on the [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n openstack-i18n mailing-list]
 
* Raise a thread to discuss the proposed change on the [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n openstack-i18n mailing-list]
 
* Lazy consensus should be preferred, but the affected project PTLs has final say on what's acceptable or not.
 
* Lazy consensus should be preferred, but the affected project PTLs has final say on what's acceptable or not.
 +
  
 
[[Category: ContribDocs]]
 
[[Category: ContribDocs]]

Revision as of 22:02, 8 September 2015

(Soft) String Freeze

String Freeze usually happens at the same time as Feature Freeze.

Once SF kicks in, you are no longer allowed to accept proposed changes containing modifications in user-facing strings. Such changes should be rejected by the review team and postponed until the next series development opens (which should happen when RC1 is published).

What's OK:

  • Adding/changing log messages
  • Adding a missing description to a config option


What's not OK:

  • Changing a user-visible API error message
  • Changing a config option name or existing description

Hard String Freeze

This happens usually when RC1 is tagged.

At this point, ideally no strings are changed, to give translator time to finish up their efforts. Ideally at least 10 working days later, another release will be made to include all the extra translated strings since the hard Freeze.

Rationale

SF ensures that the documentation and translation teams have a relatively-stable universe to produce documentation and translations for.

Its annoying to update a string just after its been translated. Adding an extra string to translate is less frustrating for them.

For log messages, its better to have an untranslated log message, rather than a hidden error condition.

Exception procedure

If you want to propose a change containing a user-facing string modification (that you believe fixes an important issue) for merging into the release under development after SF, follow those steps:

  • Mention the need for a string freeze exception on the review
  • Provide links to appropriate bugs
  • Raise a thread to discuss the proposed change on the openstack-i18n mailing-list
  • Lazy consensus should be preferred, but the affected project PTLs has final say on what's acceptable or not.
Retrieved from "https://wiki.openstack.org/w/index.php?title=StringFreeze&oldid=89792"