678833 - Update review and flags rules and clarify moa policy for SeaMonkey MailNews patches

Status: RESOLVED FIXED

(SeaMonkey :: Website, defect)

Description

[rsx11m]

Based on the discussion in bug 677905 it appears that the moa rules for requesting sr? for SeaMonkey/MailNews patches are not specific enough.

>  <li><abbr title="module owner approval">moa</abbr> (can be requested
>    via the <abbr title="super-review">sr</abbr> flag but from the mailnews
>    module owner/peer) is required for mailnews patches unless a mailnews owner
>    or peer says otherwise (this is for ensuring user data safety).</li>

My understanding so far was that it was only necessary if actual mailnews/ code shared with Thunderbird is touched, but not suite-specific suite/mailnews/ code. Reading the conversation between tonymec and mnyromyr in the IRC log apparently that interpretation was wrong. I'd suggest to phrase this part more specific that both mailnews/ or suite/mailnews/ require moa by requesting sr?.

> <h2 id="flags">Bugzilla flags</h2>
> <h3 id="blocking">blocking-seamonkey-xxx</h3>
> <h3 id="approval">approval-seamonkey-xxx</h3>

This needs to be updated for the new aurora and beta channels now that the new rapid-release process is in place with specifics what's acceptable on either channel.

Comment 1

[Justin Wood (:Callek)]

...Lets take this to newsgroup (or private -members list) and then update the website based on the outcome there.

Comment 2

[rsx11m]

For reference, this is the Thunderbird draft for channel restrictions:
http://people.mozilla.org/~mbanner2/tbdevspecifics/#channel-activities

Comment 3

[Jens Hatlak (:InvisibleSmiley)]

(In reply to rsx11m from comment #0)
> My understanding so far was that it was only necessary if actual mailnews/
> code shared with Thunderbird is touched, but not suite-specific
> suite/mailnews/ code.

Speaking from experience, I could have told you otherwise. ;-)

> I'd suggest to phrase this part more specific that both mailnews/ or
> suite/mailnews/ require moa by requesting sr?.

AFAIK MOA only applies to SM MailNews (/suite/mailnews) code. /mailnews is under the control of the TB devs, i.e. you need a TB dev SR for any changes made there. I think there are still some SM-only files there, in which case the SR request is pro forma, but still required.

> This needs to be updated for the new aurora and beta channels now that the
> new rapid-release process is in place with specifics what's acceptable on
> either channel.

Right. Suggestions welcome (a Callek vs InvisibleSmiley session maybe?). AFAIK, l10n-wise the same applies to both Aurora and Beta: No l10n changes (to en-US), with the exception of Help (where any change is allowed that does not add or remove files).

Comment 4

[Jens Hatlak (:InvisibleSmiley)]

Now that the Aurora etc. changes have been made, let's fix the MailNews issue.

Current text:
"moa (... mailnews module owner/peer) is required for mailnews patches unless a mailnews owner or peer says otherwise"

Suggestion:
"moa (... SeaMonkey MailNews module owner/peer) is required for SeaMonkey MailNews (suite/mailnews/) patches unless the SeaMonkey MailNews owner/peer says otherwise"

rsx11m, Mnyromyr, what do you think?

Comment 5

[rsx11m]

Sounds unambiguous to me now which MailNews module is meant, thanks. Obviously Mnyromyr should have the final say on the wording.

You could reduce the occurrence of "SeaMonkey MailNews" from three to just two, replacing "SeaMonkey MailNews (suite/mailnews/) patches" by "suite/mailnews/ patches" and it should still be clear in that context.

Comment 6

[Karsten Düsterloh]

(In reply to Jens Hatlak (:InvisibleSmiley) from comment #4)
> "moa (... SeaMonkey MailNews module owner/peer) is required for SeaMonkey
> MailNews (suite/mailnews/) patches unless the SeaMonkey MailNews owner/peer
> says otherwise"
(In reply to rsx11m from comment #5)
> You could reduce the occurrence of "SeaMonkey MailNews" from three to just
> two, replacing "SeaMonkey MailNews (suite/mailnews/) patches" by
> "suite/mailnews/ patches" and it should still be clear in that context.

Fine by me.

Comment 7

[Jens Hatlak (:InvisibleSmiley)]

Checking in review-and-flags.en.html;
/www/seamonkeyproject-org/src/dev/review-and-flags.en.html,v  <--  review-and-flags.en.html
new revision: 1.7; previous revision: 1.6
done