Converted CodeReview.md
diff --git a/CodeReview.md b/CodeReview.md new file mode 100644 index 0000000..3b9cae1 --- /dev/null +++ b/CodeReview.md
@@ -0,0 +1,39 @@ +# 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: + 1. 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. + 1. Push your line of development to a branch in the origin repository. + 1. Ask another Melange engineer to review every unreviewed commit in your branch. + 1. Make changes and re-push to your branch, and secure re-review as necessary. + 1. 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. + 1. Prune your development branch if it will see no further use. + +# Sample Author Commands + +## Pulling from origin +`git pull --no-rebase --no-commit` + +Without the --no-commit flag, a pull operation that requires a commit will get an auto-created commit with an auto-generated log message like "Merge branch page-fix". Because our branch names are ephemeral we suppress the auto-created commit so that we may give any merge commit a message that describes the substance of what is being merged. + +## 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.** Rebases cause us to lose review history and chronological ordering of our work. A falsely 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. \ No newline at end of file
diff --git a/CodeReview.wiki b/CodeReview.wiki deleted file mode 100644 index 28bd0fb..0000000 --- a/CodeReview.wiki +++ /dev/null
@@ -1,42 +0,0 @@ -#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}}} - -Without the --no-commit flag, a pull operation that requires a commit will get an auto-created commit with an auto-generated log message like "Merge branch page-fix". Because our branch names are ephemeral we suppress the auto-created commit so that we may give any merge commit a message that describes the substance of what is being merged. - -== 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.* Rebases cause us to lose review history and chronological ordering of our work. A falsely 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. \ No newline at end of file