Closed
Bug 678833
Opened 12 years ago
Closed 11 years ago
Update review and flags rules and clarify moa policy for SeaMonkey MailNews patches
Categories
(SeaMonkey :: Website, defect)
SeaMonkey
Website
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: rsx11m.pub, Unassigned)
References
()
Details
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•12 years ago
|
||
...Lets take this to newsgroup (or private -members list) and then update the website based on the outcome there.
For reference, this is the Thunderbird draft for channel restrictions: http://people.mozilla.org/~mbanner2/tbdevspecifics/#channel-activities
Comment 3•12 years ago
|
||
(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•11 years ago
|
||
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?
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•11 years ago
|
||
(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•11 years ago
|
||
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
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
Product: Websites → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•