Tree Rules/comm-central

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/

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.