<commit_before>Contributing To gopacket
========================

So you've got some code and you'd like it to be part of gopacket... wonderful!
We're happy to accept contributions, whether they're fixes to old protocols, new
protocols entirely, or anything else you think would improve the gopacket
library.  This document is designed to help you to do just that.

The first section deals with the plumbing:  how to actually get a change
submitted.

The second section deals with coding style... Go is great in that it
has a uniform style implemented by 'go fmt', but there's still some decisions
we've made that go above and beyond, and if you follow them, they won't come up
in your code review.

The third section deals with some of the implementation decisions we've made,
which may help you to understand the current code and which we may ask you to
conform to (or provide compelling reasons for ignoring).

Overall, we hope this document will help you to understand our system and write
great code which fits in, and help us to turn around on your code review quickly
so the code can make it into the master branch as quickly as possible.


How To Submit Code
------------------

gopacket uses the code.google.com Git version control system.  If you want to
make a new change, you'll first have to get our code:

    go get code.google.com/p/gopacket
    cd $GOROOT/src/pkg/code.google.com/p/gopacket
    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

Nw 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>, detailing your change.  We'll add
you as a committer, and you can upload your feature branch to code.google.com.
From there, the other folks working on gopacket can give you code reviews with
the code.google.com code review functionality.

The code review will generally be either emails or line-by-line reviews via
code.google.com.  One or more folks might review your code.  The review should
be considered "complete" when at least one of the project Owners (see
https://code.google.com/p/gopacket/people/list) 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 code.google.com.
    + Handle comments and requests from reviewers, pushing new commits up to
      your feature branch as problems are addressed.<commit_msg>fix typo in CONTRIBUTING.md<commit_after>Contributing To gopacket
========================

So you've got some code and you'd like it to be part of gopacket... wonderful!
We're happy to accept contributions, whether they're fixes to old protocols, new
protocols entirely, or anything else you think would improve the gopacket
library.  This document is designed to help you to do just that.

The first section deals with the plumbing:  how to actually get a change
submitted.

The second section deals with coding style... Go is great in that it
has a uniform style implemented by 'go fmt', but there's still some decisions
we've made that go above and beyond, and if you follow them, they won't come up
in your code review.

The third section deals with some of the implementation decisions we've made,
which may help you to understand the current code and which we may ask you to
conform to (or provide compelling reasons for ignoring).

Overall, we hope this document will help you to understand our system and write
great code which fits in, and help us to turn around on your code review quickly
so the code can make it into the master branch as quickly as possible.


How To Submit Code
------------------

gopacket uses the code.google.com Git version control system.  If you want to
make a new change, you'll first have to get our code:

    go get code.google.com/p/gopacket
    cd $GOROOT/src/pkg/code.google.com/p/gopacket
    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>, detailing your change.  We'll add
you as a committer, and you can upload your feature branch to code.google.com.
From there, the other folks working on gopacket can give you code reviews with
the code.google.com code review functionality.

The code review will generally be either emails or line-by-line reviews via
code.google.com.  One or more folks might review your code.  The review should
be considered "complete" when at least one of the project Owners (see
https://code.google.com/p/gopacket/people/list) 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 code.google.com.
    + Handle comments and requests from reviewers, pushing new commits up to
      your feature branch as problems are addressed.
{'fraction_non_alphanumeric': 0.05891126025354213, 'fraction_numerical': 0.0, 'mean_word_length': 3.5402843601895735, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1723778', 'n_tokens_mistral': 1737, 'n_tokens_neox': 1671, 'n_words': 1058}