Difference between revisions of "StringFreeze"
m |
(→Exception procedure) |
||
| Line 24: | Line 24: | ||
* Mention the need for a string freeze exception on the review | * Mention the need for a string freeze exception on the review | ||
* Provide links to appropriate bugs | * Provide links to appropriate bugs | ||
| − | * Raise a thread to discuss the | + | * 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. | ||
Revision as of 12:31, 20 March 2014
StringFreeze (SF) happens at the same time as FeatureFreeze.
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
Rationale
SF ensures that the documentation and translation teams have a relatively-stable universe to produce documentation and translations for.
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.
