#summary Procedure for Melange Code Review.
#labels Contents-Draft

= Requirements =

All commits and must be reviewed by at least one Melange engineer other than the author before migration to the master branch.

= Author Process =

When you feel that your current line of development is ready for review:
  # If master has advanced beyond where it was when you started your development, pull the current head of master and merge master's changes with yours.
  # Push your line of development to a branch in the origin repository.
  # Ask another Melange engineer to review every unreviewed commit in your branch.
  # Make changes and re-push to your branch, and secure re-review as necessary.
  # When every commit on your branch has been reviewed (positively), push the (reviewed) head commit of your development branch to master, taking care to make no additional changes.
  # Prune your development branch if it will see no further use.

= Sample Author Commands =

== Pulling from origin ==
{{{git pull --no-rebase --no-commit}}}

== Pushing commits to a branch for review ==
{{{git push origin <hex string of commit to be reviewed>:<review branch name>}}}

== Pushing reviewed commits to master ==
{{{git push origin <latest reviewed commit hex string, not branch name or other alias>:master}}} - this will either push your specific reviewed commits to master or fail as non-fast-forward (in which case you'll have to merge and undergo further review).

= Rebase =

*Do not rebase.* We lose review history and chronological ordering with rebases. Linear history just isn't worth it.

= Reviewer Process =
If a change looks good and needs no comment, just mark it positive and hit the "submit" button. This suppresses the per-commit email thread and cuts down on mailing list noise.

= Exceptions =

Commits made as part of the release process ("Set new Melange version number...") are exempt and may be made on master. They should still be reviewed when convenient, though.