canmove, Confirmed users, Bureaucrats and Sysops emeriti
3,628
edits
(→Thunderbird: Add outline of current tree closure reasons/rules) |
|||
| (11 intermediate revisions by the same user not shown) | |||
| Line 10: | Line 10: | ||
* Build Config (e.g. configure.in, build/, config/) | * Build Config (e.g. configure.in, build/, config/) | ||
* | * ldap/ | ||
* editor/ | * editor/ | ||
* mailnews/ | * mailnews/ | ||
* mail/ | * mail/ | ||
* other-licenses/*/thunderbird/ | * other-licenses/*/thunderbird/ | ||
==== When does the tree get closed or changed to approval required? ===== | |||
The tree is closed when: | |||
* When there is multi-platform bustage | |||
* If there are too many test failures per suite, that makes it impossible to star accurately. | |||
** e.g. 10 or more xpcshell failures happening at the same time. | |||
The tree is approval required when: | |||
* There is perma-red or perma-orange on one or more platforms. | |||
* Approval is then generally required for landing patches, except bustage-fixes. | |||
* Approval is required because | |||
** Historically, people have been seen not to star oranges before and after landing, hence this needs checking and validating | |||
** Sometimes bustage is starred incorrectly | |||
* Approval should check: | |||
** The tree is starred | |||
** The patch is unlikely to affect the bustage areas (unless it is fixing them!) | |||
*** e.g. if Mac is busted, then landing a Mac-only patch isn't a good idea. A patch that doesn't have Mac specific parts is probably fine. | |||
=== SeaMonkey === | === SeaMonkey === | ||
| Line 21: | Line 39: | ||
* other-licenses/*/seamonkey/ | * other-licenses/*/seamonkey/ | ||
=== | === Lightning === | ||
* calendar/ | * calendar/ | ||
== comm-central (Nightly channel) == | |||
* '''All changes''' must meet the [https://developer.mozilla.org/En/Developer_Guide/Committing_Rules_and_Responsibilities general checkin rules]. You must check the tree before pushing, and watch the tree for failures after pushing. | |||
* Set the ''Target Milestone'' field in Bugzilla to the current Nightly version after landing a bug fix on comm-central. | |||
* Please ask the sheriff channel (typically, #maildev, #seamonkey or #calendar depending on the application you are landing to) on [[IRC]] if you have questions. | |||
== | == comm-aurora == | ||
'''<font color="orange">APPROVAL REQUIRED</font>''' | |||
* '''All changes''' must meet the [https://developer.mozilla.org/En/Developer_Guide/Committing_Rules_and_Responsibilities general checkin rules]. You must check the tree before pushing, and watch the tree for failures after pushing. | |||
* Patches must have the '''approval-comm-aurora+''' flag in Bugzilla. To request approval, set the approval-comm-aurora? flag on the patch you wish to check in. | |||
* Patches nominated for aurora should: | |||
** have tests, or a strong statement of what can be done in the absence of tests. | |||
** have landed in comm-central to bake on the nightly channel for a few days. | |||
** have a comment in Bugzilla assessing performance impact, risk, and reasons the patch is needed on aurora. | |||
* Approval requests are processed regularly. | |||
* Set the appropriate ''status-thunderbirdN'', ''status-seamonkeyN'' flag to "fixed" after landing a fix on the Aurora branch. | |||
== comm-beta == | |||
= | '''<font color="orange">APPROVAL REQUIRED</font>''' | ||
* '''All changes''' must meet the [https://developer.mozilla.org/En/Developer_Guide/Committing_Rules_and_Responsibilities general checkin rules]. You must check the tree before pushing, and watch the tree for failures after pushing. | |||
* Patches must have the '''approval-comm-beta+''' flag in Bugzilla. To request approval, set the approval-comm-beta? flag on the patch you wish to check in. | |||
* Patches nominated for beta should: | |||
** have tests, or a strong statement of what can be done in the absence of tests. | |||
** have landed in mozilla-central to bake on the nightly channel for a few days. | |||
** have a comment in Bugzilla assessing performance impact, risk, and reasons the patch is needed on beta. | |||
** not change binary interfaces or otherwise break add-on compatibility. | |||
* Approval requests are processed regularly. | |||
* Set the appropriate ''status-thunderbirdN'', ''status-seamonkeyN'' flag to "fixed" after landing a fix on the Beta branch. | |||
== | == comm-release == | ||
'''<font color="orange">APPROVAL REQUIRED</font>''' | |||
* Patches must have the '''approval-comm-release+''' flag in Bugzilla. To request approval, set the approval-comm-release? flag on the patch you wish to check in. | |||
* In the normal development process, no changes will land on comm-release except [[RapidRelease/Calendar|regular merges from comm-beta]] every six weeks. | |||
* Changes to the release branch are limited to urgent "chemspills" like zero-day security vulnerabilities and other unplanned emergencies. Any changes to this branch will be directly overseen by the [Releases/Drivers release drivers for the appropriate product]. | |||
== comm-esr17 (Thunderbird 17.0.x ESR) == | |||
= | '''<font color="orange">APPROVAL REQUIRED</font>''' | ||
* We use the same process as the Firefox [[Release Management/ESR Landing Process]]. | |||
** Use the tracking-thunderbird-esr17 and status-thunderbird-esr17 flags instead of the Firefox ones. | |||