Browse Source

Remove a lot of stuff from CONTRIBUTING.

Some of this was due to old workflow.
Graeme Connell 2 years ago
1 changed files with 11 additions and 37 deletions
  1. 11 37

+ 11 - 37

@@ -26,8 +26,14 @@ so the code can make it into the master branch as quickly as possible.
 How To Submit Code
-gopacket uses the Git version control system.  If you want to
-make a new change, you'll first have to get our code:
+We use's Pull Request feature to receive code contributions from
+external contributors.  See
+ for details on
+how to create a request.
+Also, there's a local script `gc` in the base directory of GoPacket that
+runs a local set of checks, which should give you relatively high confidence
+that your pull won't fail github pull checks.
 go get
@@ -35,59 +41,27 @@ cd $GOROOT/src/pkg/
 git checkout -b <mynewfeature>  # create a new branch to work from
 ... code code code ...
 ./gc  # Run this to do local commits, it performs a number of checks
-... code code code ...
-./gc --benchmark  # Run this whenever your commit could affect performance
-Now that you're in the gopacket code directory, you can start making your initial
-change.  PLEASE make sure you're using a new branch to develop whatever feature
-you're working on.
-Once you've got your code to a place where you're ready to have us look at it,
-send an email to [email protected], detailing your change.  We'll add
-you as a committer, and you can upload your feature branch to
-From there, the other folks working on gopacket can give you code reviews with
-the code review functionality.
-The code review will generally be either emails or line-by-line reviews via  One or more folks might review your code.  The review should
-be considered "complete" when at least one of the project Owners (see
- gives you permission to merge to
-master.  At that point, you can merge to master yourself, or you can have one of
-the other committers/owners do it for you.
-When doing the final merge, please try to capture any interesting comments or
-discussions that came up in code review.  This will help future contributors be
-able to find and reference those discussions later on.
 To sum up:
 * DO
     + Pull down the latest version.
     + Make a feature-specific branch.
     + Code using the style and methods discussed in the rest of this document.
-    + Use the ./gc command to do local commits.
-    + Send an email asking us to make you a committer (if you're new).
-    + Push your new feature branch up to
+    + Use the ./gc command to do local commits or check correctness.
+    + Push your new feature branch up to, as a pull request.
     + Handle comments and requests from reviewers, pushing new commits up to
       your feature branch as problems are addressed.
-    + Get approval from a project Owner to merge to master.
-    + Merge yourself, or have another Committer/Owner do it for you.
     + Put interesting comments and discussions into commit comments.
 * DON'T
-    + Push directly to master.
     + Push to someone else's branch without their permission.
-    + Merge your own code to master without sign-off from others on the project.
-    + Rebase (please merge)
-    + Review others' code as it comes in (politely :)
-    + Keep contributing!
 Coding Style
-* Go code must be run through 'go fmt'.
+* Go code must be run through `go fmt`, `go vet`, and `golint`
 * Follow as much as possible.
     + In particular,  Enums
       should be be CamelCase, with acronyms capitalized (TCPSourcePort, vs.