BMO/Development Processes

Interaction Between BMO and Upstream

Security/Blocker Issues

• If filed against BMO, we should also file and possibly provide a fix for upstream
• If filed against upstream, we have to clone into the BMO product

Bugs filed against BMO

• No obligation to clone into upstream

Bugs filed against upstream

• Determine if applicable to upstream only, BMO only, or both
• If applicable to both, we should clone into the BMO product

Existing upstream bugs

• In-progress bugs
  • Triage each bug assigned to BMO team members and make a judgement call as to if we want to continue work upstream
• Upstream bugs we want
  • Clone into BMO and unassign from upstream

Other Policies

Is a bug required for X?

• Fixes to existing bugs can re-use the existing bug number (comment on the bug with the commit output)
• Any change to executable code requires a bug

Reviews

• The review should perform an "eyes-only" review within one working day
  • This involves reading the code and commenting if things look OK, or r-'ing if there are obvious issues
  • If the code reads OK, the reviewer can either leave a comment, or set the feedback flag to +
• Non-executable code does not require review (documentation, comments)
• Judgement call on if patches require review, with a strong bias towards asking for a review
  • ie. if there's any doubt then ask for a review with a comment indicating that

Commit Message

• "bug ### - summary" or "NO BUG - summary"
  • eg. "Bug 1182387: add bug.votes to api responses" and "NO BUG - fix permissions"
  • "r=glob" not required because this is tracked in Bugzilla
  • single line only