Jump to: navigation, search

StringFreeze

Revision as of 15:24, 7 March 2016 by John Garbutt (talk | contribs) (Exception procedure)

(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 log messages
  • Adding a missing description to a config option
  • Translation team may update strings if they find string mistakes or translation issues


What's not OK:

  • Adding or Changing user-visible API error messages, unless really needed
  • Changing existing strings, unless really needed
    • For example: log messages, config option name or existing description
    • Please note, there can also be a doc impact from some of the above changes, which should be avoided if possible

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.

Hard Freeze 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.