View source for 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
* 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