From d88fe6146d037ce4b0e6613e90297fa25b0471ce Mon Sep 17 00:00:00 2001 From: Andrew Gerrand Date: Wed, 10 Dec 2014 09:29:35 +1100 Subject: [PATCH] [release-branch.go1.4] [release-branch.go1.4] doc: update contribution guidelines LGTM=minux, adg, rsc R=rsc, r, dsymonds, minux, bradfitz, adg, dave, iant CC=golang-codereviews https://golang.org/cl/185190043 --- doc/contribute.html | 660 ++++++++++++++++++++++---------------------- 1 file changed, 333 insertions(+), 327 deletions(-) diff --git a/doc/contribute.html b/doc/contribute.html index 92fd88b485..ba550d5281 100644 --- a/doc/contribute.html +++ b/doc/contribute.html @@ -6,9 +6,21 @@

This document explains how to contribute changes to the Go project. -It assumes you have installed Go using the +It assumes you have installed Go from source: +

+ +

+$ git clone https://go.googlesource.com/go
+$ cd go/src
+$ ./all.bash
+
+ + +

(Note that the gccgo frontend lives elsewhere; see Contributing to gccgo.)

@@ -54,7 +66,8 @@ $ ./all.bash

-After running for a while, the command should print "ALL TESTS PASSED". +After running for a while, the command should print +"ALL TESTS PASSED".

Code review

@@ -64,208 +77,229 @@ Changes to Go must be reviewed before they are submitted, no matter who makes the change. (In exceptional cases, such as fixing a build, the review can follow shortly after submitting.) -A Mercurial extension helps manage the code review process. -The extension is included in the Go source tree but needs -to be added to your Mercurial configuration. +A custom git command called git-review, +discussed below, helps manage the code review process through a Google-hosted +instance of the code review +system called Gerrit.

-

Caveat for Mercurial aficionados

+

Set up authentication for code review

-Using Mercurial with the code review extension is not the same -as using standard Mercurial. +The Git code hosting server and Gerrit code review server both use a Google +Account to authenticate. You therefore need a Google Account to proceed. +(If you can use the account to +sign in at google.com, +you can use it to sign in to the code review server.) +The email address you use with the code review system +will be recorded in the change log +and in the CONTRIBUTORS file. +You can create a Google Account +associated with any address where you receive email.

-The Go repository is maintained as a single line of reviewed changes; -we prefer to avoid the complexity of Mercurial's arbitrary change graph. -The code review extension helps here: its hg submit command -automatically checks for and warns about the local repository -being out of date compared to the remote one. -The hg submit command also verifies other -properties about the Go repository. -For example, -it checks that Go code being checked in is formatted in the standard style, -as defined by gofmt, -and it checks that the author of the code is properly recorded for -copyright purposes. +Visit the site go.googlesource.com +and log in using your Google Account. +Click on the "Generate Password" link that appears at the top of the page.

-To help ensure changes are only created by hg submit, -the code review extension disables the standard hg commit -command. +Click the radio button that says "Only go.googlesource.com" +to use this authentication token only for the Go project.

-

Configure the extension

+

+Further down the page is a box containing commands to install +the authentication cookie in file called .gitcookies in your home +directory. +Copy the text for the commands into a Unix shell window to execute it. +That will install the authentication token. +

-

Edit .hg/hgrc in the root of your Go checkout to add:

+

+(If you are on a Windows computer, you should instead follow the instructions +in the yellow box to run the command.) +

-
-[extensions]
-codereview = /path/to/go/lib/codereview/codereview.py
+
Register with Gerrit

 
-[ui]
-username = Your Name <you@server.dom>
+

+Now that you have a Google account and the authentication token,
+you need to register your account with Gerrit, the code review system.
+To do this, visit golang.org/cl
+and log in using the same Google Account you used above.
+That is all that is required.
+

+
+
Install the git-review command

+
+

+Now install the git-review command by running,
+

+
+
+go get -u golang.org/x/review/git-review
 

 
 

-The username information will not be used unless
-you are a committer (see below), but Mercurial complains if it is missing.
+Make sure git-review is installed in your shell path, so that the
+git command can find it. Check that
 

 
+
+$ git review help
+

+ 
 

-As the codereview extension is only enabled for your Go checkout, the remainder of this document assumes you
-are inside the go directory when issuing commands.
+prints help text, not an error.
 

 
-
To contribute to subrepositories, edit the .hg/hgrc for each
-subrepository in the same way. For example, add the codereview extension to
-golang.org/x/tools/.hg/hgrc.
+

+Note to Git aficionados: The git-review command is not required to
+upload and manage Gerrit code reviews. For those who prefer plain Git, the text
+below gives the Git equivalent of each git-review command. If you do use plain
+Git, note that you still need the commit hooks that the git-review command
+configures; those hooks add a Gerrit Change-Id line to the commit
+message and check that all Go source files have been formatted with gofmt. Even
+if you intend to use plain Git for daily work, install the hooks in a new Git
+checkout by running git-review hooks).
 

 
-
Understanding the extension

+
Set up git aliases

 
-
After adding the code review extension, you can run

+

+The git-review command can be run directly from the shell
+by typing, for instance,
+

 
 
-$ hg help codereview
+$ git review sync
 

 
-
to learn more about its commands. To learn about a specific code-review-specific
-command such as change, run

+

+but it is more convenient to set up aliases for git-review's own
+subcommands, so that the above becomes,
+

 
 
-$ hg help change
+$ git sync
 

 
-

-Windows users may need to perform extra steps to get the code review
-extension working. See the
-CodeReview page
-on the Go Wiki for details.
 

-
-
Log in to the code review site.

+The git-review subcommands have been chosen to be distinct from
+Git's own, so it's safe to do so.
+

 
 

-The code review server uses a Google Account to authenticate.
-(If you can use the account to
-sign in at google.com,
-you can use it to sign in to the code review server.)
-The email address you use on the Code Review site
-will be recorded in the Mercurial change log
-and in the CONTRIBUTORS file.
-You can create a Google Account
-associated with any address where you receive email.
-If you've enabled the two-step verification feature, don't forget to generate an
-application-specific password and use that when prompted for a password.
+The aliases are optional, but in the rest of this document we will assume
+they are installed.
+To install them, copy this text into your Git configuration file
+(usually .gitconfig in your home directory):
 

 
 
-$ hg code-login
-Email (login for uploading to codereview.appspot.com): rsc@golang.org
-Password for rsc@golang.org:
-
-Saving authentication cookies to /Users/rsc/.codereview_upload_cookies_codereview.appspot.com
+[alias]
+	change = review change
+	gofmt = review gofmt
+	mail = review mail
+	pending = review pending
+	sync = review sync
 

 
-
Configure your account settings.

+
Understanding the git-review command

 
-
Edit your code review settings.
-Grab a nickname.
-Many people prefer to set the Context option to
-“Whole file” to see more context when reviewing changes.
-

+
After installing the git-review command, you can run

+
+
+$ git review help
+

 
-
Once you have chosen a nickname in the settings page, others
-can use that nickname as a shorthand for naming reviewers and the CC list.
-For example, rsc is an alias for rsc@golang.org.
+

+to learn more about its commands.
+You can also read the command documentation.
 

 
-
Switch to the default branch

+
Switch to the master branch

 
 

 Most Go installations use a release branch, but new changes should
-only be made to the default branch. (They may be applied later to a release
-branch as part of the release process.)
-Before making a change, make sure you use the default branch:
+only be made based on the master branch.
+(They may be applied later to a release branch as part of the release process,
+but most contributors won't do this themselves.)
+Before making a change, make sure you start on the master branch:
 

 
 
-$ hg update default
+$ git checkout master
+$ git sync
 

 
+

+(In Git terms, git sync runs
+git pull -r.)
+

+
 
Make a change

 
 

 The entire checked-out tree is writable.
-If you need to edit files, just edit them: Mercurial will figure out which ones changed.
-You do need to inform Mercurial of added, removed, copied, or renamed files,
-by running
-hg add,
-hg rm,
-hg cp,
-or
-hg mv.
+Once you have edited files, you must tell Git that they have been modified.
+You must also tell Git about any files that are added, removed, or renamed files.
+These operations are done with the usual Git commands,
+git add,
+git rm,
+and
+git mv.
 

 
-
When you are ready to send a change out for review, run

+

+If you wish to checkpoint your work, or are ready to send the code out for review, run

 
 
-$ hg change
+$ git change <branch>
 

 
-
from any directory in your Go repository.
-Mercurial will open a change description file in your editor.
-(It uses the editor named by the $EDITOR environment variable, vi by default.)
-The file will look like:
+

+from any directory in your Go repository to commit the changes so far.
+The name <branch> is an arbitrary one you choose to identify the
+local branch containing your changes.
 

 
-
-# Change list.
-# Lines beginning with # are ignored.
-# Multi-line values should be indented.
+

+(In Git terms, git change <branch>
+runs git checkout -b branch,
+then git branch --set-upstream-to origin/master,
+then git commit.)
+

 
-Reviewer:
-CC:
+

+Git will open a change description file in your editor.
+(It uses the editor named by the $EDITOR environment variable,
+vi by default.)
+The file will look like:
+

 
-Description:
-	<enter description here>
+
 
-Files:
-	src/math/sin.go
-	src/math/tan.go
-	src/regexp/regexp.go
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# On branch foo
+# Changes not staged for commit:
+#	modified:   editedfile.go
+#
 

 
 

-The Reviewer line lists the reviewers assigned
-to this change, and the CC line lists people to
-notify about the change.
-These can be code review nicknames or arbitrary email addresses.
-Unless explicitly told otherwise, such as in the discussion leading
-up to sending in the change list, leave the reviewer field blank.
-This means that the
-golang-codereviews@googlegroups.com
-mailing list will be used as the reviewer.
-

-
-

-Replace “<enter description here>”
-with a description of your change.
+At the beginning of this file is a blank line; replace it
+with a thorough description of your change.
 The first line of the change description is conventionally a one-line
 summary of the change, prefixed by the primary affected package,
-and is used as the subject for code review mail; the rest of the
-description elaborates.
-

-
-

-The Files section lists all the modified files
-in your client.
-It is best to keep unrelated changes in different change lists.
-In this example, we can include just the changes to package math
-by deleting the line mentioning regexp.go.
+and is used as the subject for code review mail.
+The rest of the
+description elaborates and should provide context for the
+change and explain what it does.
+If there is a helpful reference, mention it here.
 

 
 

@@ -273,343 +307,314 @@ After editing, the template might now read:
 

 
 
-# Change list.
-# Lines beginning with # are ignored.
-# Multi-line values should be indented.
+math: improved Sin, Cos and Tan precision for very large arguments
 
-Reviewer: golang-codereviews@googlegroups.com
-CC: math-nuts@swtch.com
+The existing implementation has poor numerical properties for
+large arguments, so use the McGillicutty algorithm to improve
+accuracy above 1e10.
 
-Description:
-	math: improved Sin, Cos and Tan precision for very large arguments.
+The algorithm is described at http://wikipedia.org/wiki/McGillicutty_Algorithm
 
-	See Bimmler and Shaney, ``Extreme sinusoids,'' J. Math 3(14).
-	Fixes issue 159.
+Fixes #159
 
-Files:
-	src/math/sin.go
-	src/math/tan.go
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# On branch foo
+# Changes not staged for commit:
+#	modified:   editedfile.go
+#
 

 
 

-The special sentence “Fixes issue 159.” associates
-the change with issue 159 in the Go issue tracker.
+The commented section of the file lists all the modified files in your client.
+It is best to keep unrelated changes in different change lists,
+so if you see a file listed that should not be included, abort
+the command and move that file to a different branch.
+

+
+

+The special notation "Fixes #159" associates the change with issue 159 in the
+Go issue tracker.
 When this change is eventually submitted, the issue
 tracker will automatically mark the issue as fixed.
-(These conventions are described in detail by the
-Google Project Hosting Issue Tracker documentation.)
+(There are several such conventions, described in detail in the
+GitHub Issue Tracker documentation.)
 

 
 

-Save the file and exit the editor.

+Once you have finished writing the commit message,
+save the file and exit the editor.
+

 
 

-The code review server assigns your change an issue number and URL,
-which hg change will print, something like:
+If you wish to do more editing, re-stage your changes using
+git add, and then run
 

 
 
-CL created: https://codereview.appspot.com/99999
+$ git change
 

 
+

+to update the change description and incorporate the staged changes.  The
+change description contains a Change-Id line near the bottom,
+added by a Git commit hook during the initial
+git change.
+That line is used by Gerrit to match successive uploads of the same change.
+Do not edit or delete it.
+

+
+

+(In Git terms, git change with no branch name
+runs git commit --amend.)
+
 
+
 
Mail the change for review

 
 

-Creating or uploading the change uploads a copy of the diff to the code review server,
-but it does not notify anyone about it. To do that, you need to run hg mail
-(see below).
+Once the change is ready, mail it out for review:
 

 
-
To send out a change for review, run hg mail using the change list number
-assigned during hg change:

-
 
-$ hg mail 99999
+$ git mail
 

 
-
You can add to the Reviewer: and CC: lines
-using the -r or --cc options.
-In the above example, we could have left the Reviewer and CC
-lines blank and then run:
+

+You can specify a reviewer or CC interested parties
+using the -r or -cc options.
+Both accept a comma-separated list of email addresses:
 

 
 
-$ hg mail -r golang-codereviews@googlegroups.com --cc math-nuts@swtch.com 99999
+$ git mail -r joe@golang.org -cc mabel@example.com,math-nuts@swtch.com
 

 
-
to achieve the same effect.

-
-
Note that -r and --cc cannot be spelled --r or -cc.

-
 

-If your change relates to an open issue, please add a comment to the issue
-announcing your proposed fix, including a link to your CL.
+Unless explicitly told otherwise, such as in the discussion leading
+up to sending in the change list, it's better not to specify a reviewer.
+All changes are automatically CC'ed to the
+golang-codereviews@googlegroups.com
+mailing list.
 

 
-
Reviewing code

-
 

-Running hg mail will send an email to you and the reviewers
-asking them to visit the issue's URL and make comments on the change.
-When done, the reviewer clicks “Publish and Mail comments”
-to send comments back.
+(In Git terms, git mail pushes the local committed
+changes to Gerrit using git push origin
+HEAD:refs/for/master.)
 

 
-
-
Revise and upload

-
 

-When you have revised the code and are ready for another round of review,
-you can upload your change and send mail asking the reviewers to
-please take another look (PTAL). Use the change list number
-assigned during hg change
+If your change relates to an open issue, please add a comment to the issue
+announcing your proposed fix, including a link to your CL.
 

 
-
-$ hg mail 99999
-

-
-
 

-Or to upload your change without sending a notification, run
+The code review server assigns your change an issue number and URL,
+which git mail will print, something like:
 

 
 
-$ hg upload 99999
+remote: New Changes:
+remote:   https://go-review.googlesource.com/99999 math: improved Sin, Cos and Tan precision for very large arguments
 

 
+
Reviewing code

+
 

-You will probably revise your code in response to the reviewer comments.
-You might also visit the code review web page and reply to the comments,
-letting the reviewer know that you've addressed them or explain why you
-haven't.  When you're done replying, click “Publish and Mail comments”
-to send the line-by-line replies and any other comments.
+Running git mail will send an email to you and the
+reviewers asking them to visit the issue's URL and make comments on the change.
+When done, the reviewer adds comments through the Gerrit user interface
+and clicks "Reply" to send comments back.
+You will receive a mail notification when this happens.
+You must reply through the web interface.
+(Unlike with the old Rietveld review system, replying by mail has no effect.)
 

 
+
Revise and upload

+
 

-The reviewer can comment on the new copy, and the process repeats.
-The reviewer approves the change by replying with a mail that says
-LGTM: looks good to me.
+You must respond to review comments through the web interface.
+(Unlike with the old Rietveld review system, responding by mail has no effect.)
 

 
 

-You can see a list of your pending changes by running hg pending (hg p for short).
+When you have revised the code and are ready for another round of review,
+stage those changes and use git change to update the
+commit.
+To send the update change list for another round of review,
+run git mail again.
 

 
-
Adding or removing files from an existing change

-
 

-If you need to re-edit the change description, or change the files included in the CL,
-run hg change 99999.
+The reviewer can comment on the new copy, and the process repeats.
+The reviewer approves the change by giving it a positive score
+(+1 or +2) and replying LGTM: looks good to me.
 

 
 

-Alternatively, you can use
+You can see a list of your pending changes by running git
+pending, and switch between change branches with git
+change <branch>.
 

 
-
-$ hg file 99999 somefile
-

+
Synchronize your client

 
 

-to add somefile to CL 99999, and
+While you were working, others might have submitted changes to the repository.
+To update your local branch, run
 

 
 
-$ hg file -d 99999 somefile
+$ git sync
 

 
 

-to remove somefile from the CL.
+(In git terms, git sync runs
+git pull -r.)
 

 
 

-A file may only belong to a single active CL at a time. hg file
-will issue a warning if a file is moved between changes.
+If files you were editing have changed, Git does its best to merge the
+remote changes into your local changes.
+It may leave some files to merge by hand.
 

 
-
Synchronize your client

-
-
While you were working, others might have submitted changes
-to the repository.  To update your client, run

+

+For example, suppose you have edited sin.go but
+someone else has committed an independent change.
+When you run git sync,
+you will get the (scary-looking) output:
 
 
-$ hg sync
+$ git sync
+Failed to merge in the changes.
+Patch failed at 0023 math: improved Sin, Cos and Tan precision for very large arguments
+The copy of the patch that failed is found in:
+   /home/you/repo/.git/rebase-apply/patch
+
+When you have resolved this problem, run "git rebase --continue".
+If you prefer to skip this patch, run "git rebase --skip" instead.
+To check out the original branch and stop rebasing, run "git rebase --abort".
 

 
-
(For Mercurial fans, hg sync runs hg pull -u
-but then also synchronizes the local change list state against the new data.)

-
 

-If files you were editing have changed, Mercurial does its best to merge the
-remote changes into your local changes.  It may leave some files to merge by hand.
+If this happens, run
 

 
+
+$ git status
+

+
 

-For example, suppose you have edited flag_test.go but
-someone else has committed an independent change.
-When you run hg sync, you will get the (scary-looking) output
-(emphasis added):
+to see which files failed to merge.
+The output will look something like this:
+

 
 
-$ hg sync
-adding changesets
-adding manifests
-adding file changes
-added 1 changeset with 2 changes to 2 files
-getting src/flag/flag.go
-couldn't find merge tool hgmerge
-merging src/flag/flag_test.go
-warning: conflicts during merge.
-merging src/flag/flag_test.go failed!
-1 file updated, 0 files merged, 0 files removed, 1 file unresolved
-use 'hg resolve' to retry unresolved file merges
-$
+rebase in progress; onto a24c3eb
+You are currently rebasing branch 'mcgillicutty' on 'a24c3eb'.
+  (fix conflicts and then run "git rebase --continue")
+  (use "git rebase --skip" to skip this patch)
+  (use "git rebase --abort" to check out the original branch)
+
+Unmerged paths:
+  (use "git reset HEAD <file>..." to unstage)
+  (use "git add <file>..." to mark resolution)
+
+	both modified:   sin.go
 

 
 

-The only important part in that transcript is the italicized line:
-Mercurial failed to merge your changes with the independent change.
-When this happens, Mercurial leaves both edits in the file,
-marked by <<<<<<< and
+The only important part in that transcript is the italicized "both modified"
+line: Git failed to merge your changes with the conflicting change.
+When this happens, Git leaves both sets of edits in the file,
+with conflicts marked by <<<<<<< and
 >>>>>>>.
 It is now your job to edit the file to combine them.
-Continuing the example, searching for those strings in flag_test.go
+Continuing the example, searching for those strings in sin.go
 might turn up:
 

 
 
-	VisitAll(visitor);
-<<<<<<< local
-	if len(m) != 7 {
+	arg = scale(arg)
+<<<<<<< HEAD
+	if arg > 1e9 {
 =======
-	if len(m) != 8 {
->>>>>>> other
-		t.Error("VisitAll misses some flags");
+	if arg > 1e10 {
+>>>>>>> mcgillicutty
+		largeReduce(arg)
 

 
 

-Mercurial doesn't show it, but suppose the original text that both edits
-started with was 6; you added 1 and the other change added 2,
-so the correct answer might now be 9.  First, edit the section
+Git doesn't show it, but suppose the original text that both edits
+started with was 1e8; you changed it to 1e10 and the other change to 1e9,
+so the correct answer might now be 1e10.  First, edit the section
 to remove the markers and leave the correct code:
 

 
 
-	VisitAll(visitor);
-	if len(m) != 9 {
-		t.Error("VisitAll misses some flags");
+	arg = scale(arg)
+	if arg > 1e10 {
+		largeReduce(arg)
 

 
 

-Then ask Mercurial to mark the conflict as resolved:
+Then tell Git that the conflict is resolved by running
 

 
 
-$ hg resolve -m flag_test.go
+$ git add sin.go
 

 
 

 If you had been editing the file, say for debugging, but do not
 care to preserve your changes, you can run
-hg revert flag_test.go to abandon your
-changes, but you may still need to run
-hg resolve -m to mark the conflict resolved.
+git reset HEAD sin.go
+to abandon your changes.
+Then run git rebase --continue to
+restore the change commit.
 

 
 
Reviewing code by others

 
 

-You can import a CL proposed by someone else into your local Mercurial client
-by using the hg clpatch command. Running
+You can import a change proposed by someone else into your local Git repository.
+On the Gerrit review page, click the "Download ▼" link in the upper right
+corner, copy the "Checkout" command and run it from your local Git repo.
+It should look something like this:
 

 
 
-$ hg clpatch 99999
+$ git fetch https://go.googlesource.com/review refs/changes/21/1221/1 && git checkout FETCH_HEAD
 

 
 

-will apply the latest diff for CL 99999 to your working copy. If any of the
-files referenced in CL 99999 have local modifications, clpatch
-will refuse to apply the whole diff. Once applied, CL 99999 will show up in
-the output of hg pending and others.
-

-
-

-To revert a CL you have applied locally, use the hg revert
-command. Running
-

-
-
-$ hg revert @99999
-

-
-

-will revert any files mentioned on CL 99999 to their original state. This can
-be an effective way of reverting one CL revision and applying another.
-

-
-

-Once the CL has been submitted, the next time you run hg sync
-it will be removed from your local pending list. Occasionally the pending list
-can get out of sync leaving stale references to closed or abandoned CLs.
-You can use hg change -D 99999 to remove the reference to CL 99999.
+To revert, change back to the branch you were working in.
 

 
 
Submit the change after the review

 
 

-After the code has been LGTM'ed, it is time to submit
-it to the Mercurial repository.
-

-
-

-If you are not a committer, you cannot submit the change directly.
-Instead a committer, usually the reviewer who said LGTM,
-will run:
-

-
-
-$ hg clpatch 99999
-$ hg submit 99999
-

-
-

-The submit command submits the code.  You will be listed as the
-author, but the change message will also indicate who the committer was.
-Your local client will notice that the change has been submitted
-when you next run hg sync.
+After the code has been LGTM'ed, an approver may
+submit it to the master branch using the Gerrit UI.
+There is a "Submit" button on the web page for the change
+that appears once the change is approved (marked +2).
 

 
-

-If you are a committer, you can run:
-

-
-
-$ hg submit 99999
-

-
 

 This checks the change into the repository.
 The change description will include a link to the code review,
 and the code review will be updated with a link to the change
 in the repository.
+Since the method used to integrate the changes is "Cherry Pick",
+the commit hashes in the repository will be changed by
+the submit operation.
 

 
-

-If your local copy of the repository is out of date,
-hg submit will refuse the change:
-

-
-
-$ hg submit 99999
-local repository out of date; must sync before submit
-

-
 
More information

 
 

-In addition to the information here, the Go community maintains a CodeReview wiki page.
+In addition to the information here, the Go community maintains a CodeReview wiki page.
 Feel free to contribute to this page as you learn the review process.
 

 
@@ -617,7 +622,8 @@ Feel free to contribute to this page as you learn the review process.
 
 
Files in the Go repository don't list author names,
 both to avoid clutter and to avoid having to keep the lists up to date.
-Instead, your name will appear in the Mercurial change log
+Instead, your name will appear in the
+change log
 and in the CONTRIBUTORS file
 and perhaps the AUTHORS file.
 

-- 
2.48.1