Tree Rules/comm-central: Difference between revisions

→‎Thunderbird: Add outline of current tree closure reasons/rules
(→‎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/)
* directory/
* 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/


=== Calendar ===
=== Lightning ===


* calendar/
* calendar/
* other-licenses/*/sunbird/
== comm-central (trunk) Rules ==
See above for which directories are owned by which application.
=== Thunderbird ===
'''When open: <font color="green">OPEN</font>''' to all checkins following the [https://developer.mozilla.org/en/comm-central#comm-central_tree_rules checkin rules]
Please ask on #maildev if you have questions.
=== SeaMonkey ===
'''When open: <font color="green">OPEN</font>''' to all checkins following the [https://developer.mozilla.org/en/comm-central#comm-central_tree_rules checkin rules]
Please ask on #seamonkey if you have questions.
=== Calendar ===
* Calendar strings are frozen for the 1.0 beta 1 release.
** No changes to strings are allowed.
Please ask on #calendar if you have questions.
== comm-1.9.2 (branch) Rules ==


See above for which directories are owned by which application.
== comm-central (Nightly channel) ==


=== Thunderbird ===
* '''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.


=== SeaMonkey ===
== comm-aurora ==


N/A - SeaMonkey does not participate on the 1.9.2 branch.
'''<font color="orange">APPROVAL REQUIRED</font>'''


=== Calendar ===
* '''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.


TBD.
== comm-beta ==


== comm-1.9.1 (branch) Rules ==
'''<font color="orange">APPROVAL REQUIRED</font>'''


See above for which directories are owned by which application.
* '''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.


=== Thunderbird ===
== comm-release ==
 
* Thunderbird is code frozen in preparation for the 3.0 release candidates.
* Checkins are allowed only if:
** Strings in mail/locales and editor/ui are '''not''' affected.
** The patch has ''approval-thunderbird3.0.x+'' (where 'x' is the number of the next release).
 
Note: wanted and blocking bugs do '''not''' approve a patch for check in.
 
Patches for approval must:
 
* Not affect strings in mail/locales and editor/ui.
* Land on trunk before requesting approval. Preferably to have some time baking before approval is requested.
* Be accompanied by a risk assessment as to the risk the patch poses and the reason we need to take it for the 3.0.* security releases when the approval is requested.
 
Patches are unlikely to be accepted if:
 
* They are not affecting security or stability (in the first couple of point releases this may be relaxed by drivers if there are fixes for significant regressions).
* They are high risk.
* They have no tests (some patches may be accepted without tests if there is a good reason why there aren't any, and if they can be demonstrated to be well-tested, if you need support for writing tests, please ask in #maildev).
 
Please ask on #maildev if you have questions.
 
=== SeaMonkey ===


* SeaMonkey on comm-1.9.1 is restricted to security, stability and polish fixes in the 2.0.x series
'''<font color="orange">APPROVAL REQUIRED</font>'''
* Checkins are allowed only if:
** The patch has explicit ''approval-seamonkey2.0.x+'' where x is the next upcoming non-tagged stability update.


When requesting approval, please state the (stability) risk this patch poses and the reason we need to take it for the 2.0 series.
* 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].


Please ask on #seamonkey if you have questions.
== comm-esr17 (Thunderbird 17.0.x ESR) ==


=== Calendar ===
'''<font color="orange">APPROVAL REQUIRED</font>'''


There is no active development on the comm-1.9.1 branch for Calendar.
* 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.
canmove, Confirmed users, Bureaucrats and Sysops emeriti
3,628

edits