BMO/Development Processes

From MozillaWiki
Jump to: navigation, search

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


  • 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