BMO/Development Processes

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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