|
|
| (19 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| − | __NOTOC__
| |
| − | [[StringFreeze]] (SF) happens at the same time as [[FeatureFreeze]].
| |
| | | | |
| − | === Freeze ===
| + | {{ caution|http://docs.openstack.org/project-team-guide/release-management.html|Update your links and bookmarks! You should read instead: }} |
| − | | |
| − | 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 opportunity of the change on the openstack-dev mailing-list
| |
| − | * Lazy consensus should be preferred, but the affected project PTLs has final say on what's acceptable or not.
| |
{{{header}}}
