SeaMonkey code reviews and flag rules

Author: Robert Kaiser (KaiRo) <kairo@kairo.at>

Code reviews

Note that those rules apply to suite-specific code only. Toolkit has their own review rules, and so does core Mozilla code (Gecko, shared stuff, etc).

r= from module owner or peer (of all involved modules).
sr= is required for all UI changes (note that for small UI changes it may happen to be faster to get r+sr from a super reviewer).
sr= is required if the patch was across multiple modules.
sr= is also required if any of the patch's reviewers request it - typically for non-trivial patches.

Note:

Any module owner could theoretically request moa, which would mean that he is required to approve all patches in that module. That doesn't mean he actually has to review them, that can still be done by a peer or other reviewer approved by the module owner. No SeaMonkey module owner requires moa yet though.

super-reviewers:

Bugzilla flags

All those xxx-seamonkey-yyy flags referred to below can be requested (set to "?") by anyone, only SeaMonkey Council members are allowed to set them to "+" or "-" though.

blocking-seamonkey-xxx

Criteria for +
- We can't ship the relevant release without that issue fixed, and would push out the release for that
- security issues should be blockers in almost any case
- severe usability issues block a final; if the vast majority of testers can live with them, they might not block alpha though
- high-profile crashes or hangs
- Only high severity issues block an alpha, less severe bugs might also block a beta or final
Criteria for - (anything meeting one of those can be minused without further discussion)
- minor glitches
- enhancements, feature requests (exceptions are when a Council majority thinks we need them for the release)
- things that weren't fixed in older final releases and did not harm there (as long as circumstances haven't changed radically)

Notes:

We may end up in having blockers without an assignee. We (Council) need to make sure we get someone working on them, so we can get a release done.
Nice-to-have improvements that don't fix major problems don't block the release. Their patches might get approved, but the bugs get blocking- in almost any case.
We should try to keep the number of blocking+ bugs as small as possible. Remember that from the definition of the flags, the number of open blockers has to be '''zero''' to ship the release. We shouldn't slip that definition by far, ideally we should meet it.

approval-seamonkey-xxx

Criteria for +
- Low risk (beta: very low risk, final: minimum risk)
- no L10n string changes
- polish, stability improvement, or routine change (version number etc.)
- patch is ready and reviewed
- patch is tested well enough for the risk involved
Criteria for - (anything meeting one of those can be minused without further discussion)

L10n string changes (esp. after a L10n freeze)
High risk, low value

General advice: Developers should include risk estimation and level of testing the patch got when requesting approval.