Approving/Rejecting Freeze Breaks
If you think that you need to break a freeze then you should ask for approval. You need
for string freeze breaks (who have quite complicated rules for when they apply and when they don't. Email if in doubt) 2 approvals from the Translation Coordination team (to contact via gnome-i18n at gnome.org) plus notification to (release-team at gnome.org) and documentation team.
for UI breaks 2 approvals from the release-team (release-team at gnome.org) plus notification to documentation team.
for Feature breaks 2 approvals from the release-team (release-team at gnome.org) plus notification to documentation team.
for Hardcode breaks 2 approvals from the release-team (release-team at gnome.org).
Note that the release-team does get a lot of requests, so please have a little patience. However, if you don't get a firm reply within 2 days, please do remind the release-team - we don't want to get in the way.
To avoid delays, please make life easier by:
- Make sure to CC the right people (the maintainer or mailing list, in addition to gnome-i18n and gnome-doc-list as needed)
- Let us know that the module's maintainer has approved the patch on the condition that we approve it (if they haven't, make sure to get their approval first).
- Clearly tell us if it is an API break, a UI change, a feature change, a string change, several categories of these, etc..
- Briefly explain what the bug being fixed is and its impact (how many people will be affected, how will they be affected, etc.) Bear in mind that many members of the docs and i18n teams are not coders, and will not be able to make sense of the patch itself.
- Tell us why you think the change should not wait for the next development phase (unless already covered in explaining the bug impact).
- Let us know of anything you've done to make the freeze break safer (why the patch might not be as scary as it looks, how hard would it be to revert if it turned out to be necessary to do so, who else has reviewed the patch, who has tested it, how much testing was done, etc.)
- Attach the patch to your mail requesting freeze break (it allows easier to review)
- Include a URL to the Bugzilla bug report with the patch.
- If you want to break the Hard Code Freeze, then please persuade us that the patch is very safe or has been very well tested (or that the situation is bad enough currently that it couldn't really get worse with a new patch, e.g. crashes easily and often).