Updates to ContributionReviews wiki
- add pointers to Gerrit page.
- comment out some obsolete sections we're not ready to delete yet
- fix line wrapping in a few places
- misc updates and tweaks
(this page still needs more updates)
diff --git a/ContributionReviews.wiki b/ContributionReviews.wiki
index 2781c60..b8d31bd 100644
--- a/ContributionReviews.wiki
+++ b/ContributionReviews.wiki
@@ -29,6 +29,7 @@
[TestingGuidelines testing] that are important to the community as a
whole are adhered to by each contributor and for each contribution.
+<wiki:comment>
Each committer will:
* be a project member (or possibly project owner) at http://code.google.com/p/soc/
@@ -36,6 +37,7 @@
* have an account at at [http://mail.google.com/a/googleopensourceprograms.com googleopensourceprograms.com]
* be able to [ContributionReviews#Using_Rietveld_for_code_reviews conduct code reviews] at http://codereviews.googleopensourceprograms.com/
* have `ACCESS` template `VOP` (`AUTOVOICE`) in the [IrcChannelGuidelines `#melange` IRC channel]
+</wiki:comment>
=== Casual contributors ===
@@ -70,10 +72,23 @@
=== Patches ===
The term "patches" is used to refer to relatively small changes to the
-code (and, yes, this definition is intentionally vague). Usually these are in the form of output from the `git diff` command.
+code (and, yes, this definition is intentionally vague).
-Patches should be sent for review to the [MailingListsGuidelines#Developer_list developer mailing list] and presented in the "unified `diff`" format, which is de-facto standard for many tools and the output from the `git diff` command (the same format as that produced by `diff -uNr`).
-Using Git:
+Patches should be sent for review via our [Gerrit] instance.
+
+=== Patchfiles ===
+
+It is prefered that all Patches be sent via Gerrit, but if you need to
+create a traditional Patchfile, you can follow these instructions:
+
+Usually these
+are in the form of output from the `git diff` command.
+
+Patches should be sent for review to the
+[MailingListsGuidelines#Developer_list developer mailing list] and
+presented in the "unified `diff`" format, which is de-facto standard
+for many tools and the output from the `git diff` command (the same
+format as that produced by `diff -uNr`). Using Git:
{{{
git diff --no-prefix > your-patch-name.patch
@@ -99,6 +114,7 @@
working copy with `patch`. Such a diff attachment can be produced with
the methods described above.
+<wiki:comment>
==== Suggested patches from casual contributors ====
The Melange community is interested in patches and other contributions
@@ -121,7 +137,15 @@
Once the patch is accepted, a committer will patch a working copy and commit
the changed (or added or deleted) source files to the repository,
supplying a suitable commit log message.
+</wiki:comment>
+==== Code Review ====
+
+Code review happens in the [Gerrit] system.
+
+All patches need a +2 from a Comitter before they can be submitted.
+
+<wiki:comment>
==== Reviews after committed patches ====
Contributors with [ContributionReviews#Committers commit access] can submit
@@ -150,54 +174,70 @@
This feature can also be used by project owners and members to do review-after-commit
style code reviews.
+</wiki:comment>
+
=== Committing ===
Once all of the
-[TestingGuidelines#All_changes_should_pass_smoke_tests_before_review pre-commit tests]
-pass and the [ContributionReviews#Patches patch has been code-reviewed]
-a [ContributionReviews#Committers committer] (who may or
-[ContributionReviews#Suggested_patches_from_casual_contributors may not]
-be the actual contributor), `hg commit` can be used to commit the change into
-the
+[TestingGuidelines#All_changes_should_pass_smoke_tests_before_review
+pre-commit tests] pass *and* the [ContributionReviews#Patches patch
+has been code-reviewed] a [ContributionReviews#Committers committer]
+(who may or
+[ContributionReviews#Suggested_patches_from_casual_contributors may
+not] be the actual contributor), the submit button in [Gerrit] or `git
+merge && git push` can be used to commit the change into the
[http://code.google.com/p/soc/source/browse SoC project repository].
==== commit messages ====
-Committers should use the template below for `hg commit` log messages:
+Committers should use the template below for `git commit` log messages:
{{{
-One line, under 70 characters giving a short description of the change
+One line, under 68 characters giving a short description of the change
-After a blank line, a more detailed log message explaining the
-reason of the change (not necessarily what was changed,
-as that can be seen by readin the patch). Please wrap your lines
-at 70 characters again.
+After a blank line, a more detailed log message explaining the reason
+of the change (not necessarily what was changed, as that can be seen
+by readin the patch). Please wrap your lines at 70 characters again.
}}}
-Optionally if committing contributor patch please include:
+If committing contributor patch (outside of Gerrit) please include:
{{{
Reviewed by: Rick Reviewer
}}}
-Note that previously the person listed with "Patch by:" was the contributor (that
-is, author) of the patch, however we have switched to Mercurial and now we are committing patch from contributors as if they would have commit access using command:
+Note that previously the person listed with "Patch by:" was the
+contributor (that is, author) of the patch, however we have switched
+to Git and now we are committing patch from contributors as if
+they would have commit access using command:
{{{
-hg commit -u "FirstName LastName <somebody@example.com>"
+git commit -u "FirstName LastName <somebody@example.com>"
}}}
-Patches from [ContributionReviews#Suggested_patches_from_casual_contributors casual contributors] will, by definition, need to be committed by someone other than the
-author but Mercurial repository history will indicate contributor as committer.
+Patches from
+[ContributionReviews#Suggested_patches_from_casual_contributors casual
+contributors] will, by definition, need to be committed by someone
+other than the author but Git repository history will indicate
+contributor as committer.
== Documentation ==
-Code files should include enough internal documentation in the form of `__doc__` strings, comments and functions with self-explanatory names (see PythonStyleGuide) that the automatic documentation suffices. This is the recommended way to ensure that code documentation and the code itself stay in step.
+Code files should include enough internal documentation in the form of
+`__doc__` strings, comments and functions with self-explanatory names
+(see PythonStyleGuide) that the automatic documentation suffices.
+This is the recommended way to ensure that code documentation and the
+code itself stay in step.
-The wiki is in the transition zone between dialog (IRC and mailing lists) and formally reviewed content (code and its comments). Changes to the wiki are 'review after commit'. Anyone can log comments for a wiki page and participate in review. At the moment rights to create pages and edit pages directly are restricted to committers and regular contributors to documentation.
+The wiki is in the transition zone between dialog (IRC and mailing
+lists) and formally reviewed content (code and its comments). Changes
+to the wiki are 'review after commit'. Any committer can log comments
+for a wiki page and participate in review. At the moment rights to
+create pages and edit pages directly are restricted to committers and
+regular contributors to documentation.
----
_Copyright 2008 Google Inc._
_This work is licensed under a_
[http://soc.googlecode.com/svn/wiki/html/licenses/cc-by-attribution-2_5.html Creative Commons Attribution 2.5 License].
-[http://creativecommons.org/licenses/by/2.5/ http://soc.googlecode.com/svn/wiki/html/licenses/cc-by-2_5-88x31.png]
\ No newline at end of file
+[http://creativecommons.org/licenses/by/2.5/ http://soc.googlecode.com/svn/wiki/html/licenses/cc-by-2_5-88x31.png]
