Tree Rules/comm-central: Difference between revisions
Jump to navigation
Jump to search
(→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. | |||
Latest revision as of 07:44, 6 October 2014
Due to multiple applications using comm-central different parts of comm-central can have different rules at different times. We try to keep these as simple as possible, if in doubt, please ask on irc.
Owned Areas
These are the directories and areas which are seen as "owned" by a particular comm-central application. The tree rules for each app apply to these directories and files.
Thunderbird
Thunderbird Rules affect these directories & areas in comm-central:
- Build Config (e.g. configure.in, build/, config/)
- ldap/
- editor/
- mailnews/
- mail/
- 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
- suite/
- other-licenses/*/seamonkey/
Lightning
- calendar/
comm-central (Nightly channel)
- All changes must meet the 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
APPROVAL REQUIRED
- All changes must meet the 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
APPROVAL REQUIRED
- All changes must meet the 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
APPROVAL REQUIRED
- 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 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)
APPROVAL REQUIRED
- 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.