Refactor docs about contributions to CONTRIBUTING.md.

Per the review comments.
8 years ago · 23a014ab57
parent c82cd5e41e
commit 23a014ab57
8 changed files with 132 additions and 364 deletions
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@ -21,8 +21,16 @@ accept your pull requests.
 ## Contributing A Patch
-1. Submit an issue describing your proposed change to the repo in question.
+1. Submit an issue describing your proposed change to the
-1. The repo owner will respond to your issue promptly.
+   [issue tracker](https://github.com/google/googletest).
 1. Please don't mix more than one logical change per submittal,
   because it makes the history hard to follow. If you want to make a
   change that doesn't have a corresponding issue in the issue
   tracker, please create one.
 1. Also, coordinate with team members that are listed on the issue in
   question. This ensures that work isn't being duplicated and
   communicating your plan early also generally leads to better
   patches.
 1. If your proposed change is accepted, and you haven't already done so, sign a
   Contributor License Agreement (see details above).
 1. Fork the desired repo, develop and test your code changes.
@ -31,7 +39,122 @@ accept your pull requests.
 1. Ensure that your code has an appropriate set of unit tests which all pass.
 1. Submit a pull request.
 If you are a Googler, it is preferable to first create an internal change and
 have it reviewed and submitted, and then create an upstreaming pull
 request here. 
 ## The Google Test and Google Mock Communities ##
 The Google Test community exists primarily through the
 [discussion group](http://groups.google.com/group/googletestframework)
 and the GitHub repository.
 Likewise, the Google Mock community exists primarily through their own
 [discussion group](http://groups.google.com/group/googlemock).
 You are definitely encouraged to contribute to the
 discussion and you can also help us to keep the effectiveness of the
 group high by following and promoting the guidelines listed here.
 ### Please Be Friendly ###
 Showing courtesy and respect to others is a vital part of the Google
 culture, and we strongly encourage everyone participating in Google
 Test development to join us in accepting nothing less. Of course,
 being courteous is not the same as failing to constructively disagree
 with each other, but it does mean that we should be respectful of each
 other when enumerating the 42 technical reasons that a particular
 proposal may not be the best choice. There's never a reason to be
 antagonistic or dismissive toward anyone who is sincerely trying to
 contribute to a discussion.
 Sure, C++ testing is serious business and all that, but it's also
 a lot of fun. Let's keep it that way. Let's strive to be one of the
 friendliest communities in all of open source.
 As always, discuss Google Test in the official GoogleTest discussion group.
 You don't have to actually submit code in order to sign up. Your participation
 itself is a valuable contribution.
 ## Style
-Samples in this repository follow the [Google C++ Style Guide](
+To keep the source consistent, readable, diffable and easy to merge,
-https://google.github.io/styleguide/cppguide.html).
+we use a fairly rigid coding style, as defined by the [google-styleguide](https://github.com/google/styleguide) project.  All patches will be expected
 to conform to the style outlined [here](https://google.github.io/styleguide/cppguide.html).
 ## Requirements for Contributors ###
 If you plan to contribute a patch, you need to build Google Test,
 Google Mock, and their own tests from a git checkout, which has
 further requirements:
  * [Python](https://www.python.org/) v2.3 or newer (for running some of
    the tests and re-generating certain source files from templates)
  * [CMake](https://cmake.org/) v2.6.4 or newer
  * [GNU Build System](https://en.wikipedia.org/wiki/GNU_Build_System)
    including automake (>= 1.9), autoconf (>= 2.59), and
    libtool / libtoolize.
 ## Developing Google Test ##
 This section discusses how to make your own changes to Google Test.
 ### Testing Google Test Itself ###
 To make sure your changes work as intended and don't break existing
 functionality, you'll want to compile and run Google Test's own tests.
 For that you can use CMake:
    mkdir mybuild
    cd mybuild
    cmake -Dgtest_build_tests=ON ${GTEST_DIR}
 Make sure you have Python installed, as some of Google Test's tests
 are written in Python.  If the cmake command complains about not being
 able to find Python (`Could NOT find PythonInterp (missing:
 PYTHON_EXECUTABLE)`), try telling it explicitly where your Python
 executable can be found:
    cmake -DPYTHON_EXECUTABLE=path/to/python -Dgtest_build_tests=ON ${GTEST_DIR}
 Next, you can build Google Test and all of its own tests.  On \*nix,
 this is usually done by 'make'.  To run the tests, do
    make test
 All tests should pass.
 ### Regenerating Source Files ##
 Some of Google Test's source files are generated from templates (not
 in the C++ sense) using a script.
 For example, the
 file include/gtest/internal/gtest-type-util.h.pump is used to generate
 gtest-type-util.h in the same directory.
 You don't need to worry about regenerating the source files
 unless you need to modify them.  You would then modify the
 corresponding `.pump` files and run the '[pump.py](googletest/scripts/pump.py)'
 generator script.  See the [Pump Manual](googletest/docs/PumpManual.md).
 ## Developing Google Mock ###
 This section discusses how to make your own changes to Google Mock.
 #### Testing Google Mock Itself ####
 To make sure your changes work as intended and don't break existing
 functionality, you'll want to compile and run Google Test's own tests.
 For that you'll need Autotools.  First, make sure you have followed
 the instructions above to configure Google Mock.
 Then, create a build output directory and enter it.  Next,
    ${GMOCK_DIR}/configure  # try --help for more info
 Once you have successfully configured Google Mock, the build steps are
 standard for GNU-style OSS packages.
    make        # Standard makefile following GNU conventions
    make check  # Builds and runs all tests - all should pass.
 Note that when building your project against Google Mock, you are building
 against Google Test as well.  There is no need to configure Google Test
 separately.
--- a/README.md
+++ b/README.md
@ -114,35 +114,9 @@ package (as described below):
  * Mac OS X v10.4 Tiger or newer
  * Xcode Developer Tools
-### Requirements for Contributors ###
+## Contributing change
-We welcome patches.  If you plan to contribute a patch, you need to
+Please read the [`CONTRIBUTING.md`](CONTRIBUTING.md) for details on
-build Google Test and its own tests from a git checkout (described
+how to contribute to this project.
 below), which has further requirements:
  * [Python](https://www.python.org/) v2.3 or newer (for running some of
    the tests and re-generating certain source files from templates)
  * [CMake](https://cmake.org/) v2.6.4 or newer
 ## Regenerating Source Files ##
 Some of Google Test's source files are generated from templates (not
 in the C++ sense) using a script.
 For example, the
 file include/gtest/internal/gtest-type-util.h.pump is used to generate
 gtest-type-util.h in the same directory.
 You don't need to worry about regenerating the source files
 unless you need to modify them.  You would then modify the
 corresponding `.pump` files and run the '[pump.py](googletest/scripts/pump.py)'
 generator script.  See the [Pump Manual](googletest/docs/PumpManual.md).
 ### Contributing Code ###
 We welcome patches.  Please read the
 [Developer's Guide](googletest/docs/DevGuide.md)
 for how you can contribute. In particular, make sure you have signed
 the Contributor License Agreement, or we won't be able to accept the
 patch.
 Happy testing!
--- a/googlemock/README.md
+++ b/googlemock/README.md
@ -337,38 +337,6 @@ use the new matcher API (
 [polymorphic](./docs/CookBook.md#writing-new-polymorphic-matchers)).
 Matchers defined using `MATCHER()` or `MATCHER_P*()` aren't affected.
 ### Developing Google Mock ###
 This section discusses how to make your own changes to Google Mock.
 #### Testing Google Mock Itself ####
 To make sure your changes work as intended and don't break existing
 functionality, you'll want to compile and run Google Test's own tests.
 For that you'll need Autotools.  First, make sure you have followed
 the instructions above to configure Google Mock.
 Then, create a build output directory and enter it.  Next,
    ${GMOCK_DIR}/configure  # try --help for more info
 Once you have successfully configured Google Mock, the build steps are
 standard for GNU-style OSS packages.
    make        # Standard makefile following GNU conventions
    make check  # Builds and runs all tests - all should pass.
 Note that when building your project against Google Mock, you are building
 against Google Test as well.  There is no need to configure Google Test
 separately.
 #### Contributing a Patch ####
 We welcome patches.
 Please read the [Developer's Guide](docs/DevGuide.md)
 for how you can contribute. In particular, make sure you have signed
 the Contributor License Agreement, or we won't be able to accept the
 patch.
 Happy testing!
 [gtest_readme]: ../googletest/README.md "googletest"
--- a/googlemock/docs/DevGuide.md
+++ b/googlemock/docs/DevGuide.md
@ -1,132 +0,0 @@
 If you are interested in understanding the internals of Google Mock,
 building from source, or contributing ideas or modifications to the
 project, then this document is for you.
 # Introduction #
 First, let's give you some background of the project.
 ## Licensing ##
 All Google Mock source and pre-built packages are provided under the [New BSD License](http://www.opensource.org/licenses/bsd-license.php).
 ## The Google Mock Community ##
 The Google Mock community exists primarily through the [discussion group](http://groups.google.com/group/googlemock), the
 [issue tracker](https://github.com/google/googletest/issues) and, to a lesser extent, the [source control repository](../). You are definitely encouraged to contribute to the
 discussion and you can also help us to keep the effectiveness of the
 group high by following and promoting the guidelines listed here.
 ### Please Be Friendly ###
 Showing courtesy and respect to others is a vital part of the Google
 culture, and we strongly encourage everyone participating in Google
 Mock development to join us in accepting nothing less. Of course,
 being courteous is not the same as failing to constructively disagree
 with each other, but it does mean that we should be respectful of each
 other when enumerating the 42 technical reasons that a particular
 proposal may not be the best choice. There's never a reason to be
 antagonistic or dismissive toward anyone who is sincerely trying to
 contribute to a discussion.
 Sure, C++ testing is serious business and all that, but it's also
 a lot of fun. Let's keep it that way. Let's strive to be one of the
 friendliest communities in all of open source.
 ### Where to Discuss Google Mock ###
 As always, discuss Google Mock in the official [Google C++ Mocking Framework discussion group](http://groups.google.com/group/googlemock).  You don't have to actually submit
 code in order to sign up. Your participation itself is a valuable
 contribution.
 # Working with the Code #
 If you want to get your hands dirty with the code inside Google Mock,
 this is the section for you.
 ## Checking Out the Source from Subversion ##
 Checking out the Google Mock source is most useful if you plan to
 tweak it yourself.  You check out the source for Google Mock using a
 [Subversion](http://subversion.tigris.org/) client as you would for any
 other project hosted on Google Code.  Please see the instruction on
 the [source code access page](../) for how to do it.
 ## Compiling from Source ##
 Once you check out the code, you can find instructions on how to
 compile it in the [README](../README.md) file.
 ## Testing ##
 A mocking framework is of no good if itself is not thoroughly tested.
 Tests should be written for any new code, and changes should be
 verified to not break existing tests before they are submitted for
 review. To perform the tests, follow the instructions in [README](../README.md) and
 verify that there are no failures.
 # Contributing Code #
 We are excited that Google Mock is now open source, and hope to get
 great patches from the community. Before you fire up your favorite IDE
 and begin hammering away at that new feature, though, please take the
 time to read this section and understand the process. While it seems
 rigorous, we want to keep a high standard of quality in the code
 base.
 ## Contributor License Agreements ##
 You must sign a Contributor License Agreement (CLA) before we can
 accept any code.  The CLA protects you and us.
  * If you are an individual writing original source code and you're sure you own the intellectual property, then you'll need to sign an [individual CLA](http://code.google.com/legal/individual-cla-v1.0.html).
  * If you work for a company that wants to allow you to contribute your work to Google Mock, then you'll need to sign a [corporate CLA](http://code.google.com/legal/corporate-cla-v1.0.html).
 Follow either of the two links above to access the appropriate CLA and
 instructions for how to sign and return it.
 ## Coding Style ##
 To keep the source consistent, readable, diffable and easy to merge,
 we use a fairly rigid coding style, as defined by the [google-styleguide](https://github.com/google/styleguide) project.  All patches will be expected
 to conform to the style outlined [here](https://google.github.io/styleguide/cppguide.html).
 ## Submitting Patches ##
 Please do submit code. Here's what you need to do:
  1. Normally you should make your change against the SVN trunk instead of a branch or a tag, as the latter two are for release control and should be treated mostly as read-only.
  1. Decide which code you want to submit. A submission should be a set of changes that addresses one issue in the [Google Mock issue tracker](https://github.com/google/googletest/issues). Please don't mix more than one logical change per submittal, because it makes the history hard to follow. If you want to make a change that doesn't have a corresponding issue in the issue tracker, please create one.
  1. Also, coordinate with team members that are listed on the issue in question. This ensures that work isn't being duplicated and communicating your plan early also generally leads to better patches.
  1. Ensure that your code adheres to the [Google Mock source code style](#Coding_Style.md).
  1. Ensure that there are unit tests for your code.
  1. Sign a Contributor License Agreement.
  1. Create a patch file using `svn diff`.
  1. We use [Rietveld](http://codereview.appspot.com/) to do web-based code reviews.  You can read about the tool [here](https://github.com/rietveld-codereview/rietveld/wiki).  When you are ready, upload your patch via Rietveld and notify `googlemock@googlegroups.com` to review it.  There are several ways to upload the patch.  We recommend using the [upload\_gmock.py](../scripts/upload_gmock.py) script, which you can find in the `scripts/` folder in the SVN trunk.
 ## Google Mock Committers ##
 The current members of the Google Mock engineering team are the only
 committers at present. In the great tradition of eating one's own
 dogfood, we will be requiring each new Google Mock engineering team
 member to earn the right to become a committer by following the
 procedures in this document, writing consistently great code, and
 demonstrating repeatedly that he or she truly gets the zen of Google
 Mock.
 # Release Process #
 We follow the typical release process for Subversion-based projects:
  1. A release branch named `release-X.Y` is created.
  1. Bugs are fixed and features are added in trunk; those individual patches are merged into the release branch until it's stable.
  1. An individual point release (the `Z` in `X.Y.Z`) is made by creating a tag from the branch.
  1. Repeat steps 2 and 3 throughout one release cycle (as determined by features or time).
  1. Go back to step 1 to create another release branch and so on.
 ---
 This page is based on the [Making GWT Better](http://code.google.com/webtoolkit/makinggwtbetter.html) guide from the [Google Web Toolkit](http://code.google.com/webtoolkit/) project.  Except as otherwise [noted](http://code.google.com/policies.html#restrictions), the content of this page is licensed under the [Creative Commons Attribution 2.5 License](http://creativecommons.org/licenses/by/2.5/).
--- a/googlemock/docs/Documentation.md
+++ b/googlemock/docs/Documentation.md
@ -11,5 +11,5 @@ the respective git branch/tag).**
 To contribute code to Google Mock, read:
-  * [DevGuide](DevGuide.md) -- read this _before_ writing your first patch.
+  * [CONTRIBUTING](../CONTRIBUTING.md) -- read this _before_ writing your first patch.
  * [Pump Manual](../../googletest/docs/PumpManual.md) -- how we generate some of Google Mock's source files.
--- a/googletest/README.md
+++ b/googletest/README.md
@ -358,38 +358,3 @@ instead of
    TEST(SomeTest, DoesThis) { ... }
 in order to define a test.
 ## Developing Google Test ##
 This section discusses how to make your own changes to Google Test.
 ### Testing Google Test Itself ###
 To make sure your changes work as intended and don't break existing
 functionality, you'll want to compile and run Google Test's own tests.
 For that you can use CMake:
    mkdir mybuild
    cd mybuild
    cmake -Dgtest_build_tests=ON ${GTEST_DIR}
 Make sure you have Python installed, as some of Google Test's tests
 are written in Python.  If the cmake command complains about not being
 able to find Python (`Could NOT find PythonInterp (missing:
 PYTHON_EXECUTABLE)`), try telling it explicitly where your Python
 executable can be found:
    cmake -DPYTHON_EXECUTABLE=path/to/python -Dgtest_build_tests=ON ${GTEST_DIR}
 Next, you can build Google Test and all of its own tests.  On \*nix,
 this is usually done by 'make'.  To run the tests, do
    make test
 All tests should pass.
 Normally you don't need to worry about regenerating the source files,
 unless you need to modify them.  In that case, you should modify the
 corresponding .pump files instead and run the pump.py Python script to
 regenerate them.  You can find pump.py in the [scripts/](scripts/) directory.
 Read the [Pump manual](docs/PumpManual.md) for how to use it.
--- a/googletest/docs/DevGuide.md
+++ b/googletest/docs/DevGuide.md
@ -1,130 +0,0 @@
 If you are interested in understanding the internals of Google Test,
 building from source, or contributing ideas or modifications to the
 project, then this document is for you.
 # Introduction #
 First, let's give you some background of the project.
 ## Licensing ##
 All Google Test source and pre-built packages are provided under the [New BSD License](http://www.opensource.org/licenses/bsd-license.php).
 ## The Google Test Community ##
 The Google Test community exists primarily through the [discussion group](http://groups.google.com/group/googletestframework) and the GitHub repository.
 You are definitely encouraged to contribute to the
 discussion and you can also help us to keep the effectiveness of the
 group high by following and promoting the guidelines listed here.
 ### Please Be Friendly ###
 Showing courtesy and respect to others is a vital part of the Google
 culture, and we strongly encourage everyone participating in Google
 Test development to join us in accepting nothing less. Of course,
 being courteous is not the same as failing to constructively disagree
 with each other, but it does mean that we should be respectful of each
 other when enumerating the 42 technical reasons that a particular
 proposal may not be the best choice. There's never a reason to be
 antagonistic or dismissive toward anyone who is sincerely trying to
 contribute to a discussion.
 Sure, C++ testing is serious business and all that, but it's also
 a lot of fun. Let's keep it that way. Let's strive to be one of the
 friendliest communities in all of open source.
 As always, discuss Google Test in the official GoogleTest discussion group.
 You don't have to actually submit code in order to sign up. Your participation
 itself is a valuable contribution.
 # Working with the Code #
 If you want to get your hands dirty with the code inside Google Test,
 this is the section for you.
 ## Compiling from Source ##
 Once you check out the code, you can find instructions on how to
 compile it in the [README](../README.md) file.
 ## Testing ##
 A testing framework is of no good if itself is not thoroughly tested.
 Tests should be written for any new code, and changes should be
 verified to not break existing tests before they are submitted for
 review. To perform the tests, follow the instructions in
 [README](../README.md) and verify that there are no failures.
 # Contributing Code #
 We are excited that Google Test is now open source, and hope to get
 great patches from the community. Before you fire up your favorite IDE
 and begin hammering away at that new feature, though, please take the
 time to read this section and understand the process. While it seems
 rigorous, we want to keep a high standard of quality in the code
 base.
 ## Contributor License Agreements ##
 You must sign a Contributor License Agreement (CLA) before we can
 accept any code.  The CLA protects you and us.
  * If you are an individual writing original source code and you're sure you own the intellectual property, then you'll need to sign an [individual CLA](http://code.google.com/legal/individual-cla-v1.0.html).
  * If you work for a company that wants to allow you to contribute your work to Google Test, then you'll need to sign a [corporate CLA](http://code.google.com/legal/corporate-cla-v1.0.html).
 Follow either of the two links above to access the appropriate CLA and
 instructions for how to sign and return it.
 ## Coding Style ##
 To keep the source consistent, readable, diffable and easy to merge,
 we use a fairly rigid coding style, as defined by the [google-styleguide](https://github.com/google/styleguide) project.  All patches will be expected
 to conform to the style outlined [here](https://google.github.io/styleguide/cppguide.html).
 ## Updating Generated Code ##
 Some of Google Test's source files are generated by the Pump tool (a
 Python script).  If you need to update such files, please modify the
 source (`foo.h.pump`) and re-generate the C++ file using Pump.  You
 can read the PumpManual for details.
 ## Submitting Patches ##
 Please do submit code. Here's what you need to do:
  1. A submission should be a set of changes that addresses one issue in the [issue tracker](https://github.com/google/googletest/issues). Please don't mix more than one logical change per submittal, because it makes the history hard to follow. If you want to make a change that doesn't have a corresponding issue in the issue tracker, please create one.
  1. Also, coordinate with team members that are listed on the issue in question. This ensures that work isn't being duplicated and communicating your plan early also generally leads to better patches.
  1. Ensure that your code adheres to the [Google Test source code style](#Coding_Style.md).
  1. Ensure that there are unit tests for your code.
  1. Sign a Contributor License Agreement.
  1. Create a Pull Request in the usual way.
 If you are a Googler, it is preferable to first create an internal change and
 have it reviewed and submitted, and then create an upstreaming pull
 request here. 
 ## Google Test Committers ##
 The current members of the Google Test engineering team are the only
 committers at present. In the great tradition of eating one's own
 dogfood, we will be requiring each new Google Test engineering team
 member to earn the right to become a committer by following the
 procedures in this document, writing consistently great code, and
 demonstrating repeatedly that he or she truly gets the zen of Google
 Test.
 # Release Process #
 We follow a typical release process:
  1. A release branch named `release-X.Y` is created.
  1. Bugs are fixed and features are added in trunk; those individual patches are merged into the release branch until it's stable.
  1. An individual point release (the `Z` in `X.Y.Z`) is made by creating a tag from the branch.
  1. Repeat steps 2 and 3 throughout one release cycle (as determined by features or time).
  1. Go back to step 1 to create another release branch and so on.
 ---
 This page is based on the [Making GWT Better](http://code.google.com/webtoolkit/makinggwtbetter.html) guide from the [Google Web Toolkit](http://code.google.com/webtoolkit/) project.  Except as otherwise [noted](http://code.google.com/policies.html#restrictions), the content of this page is licensed under the [Creative Commons Attribution 2.5 License](http://creativecommons.org/licenses/by/2.5/).
--- a/googletest/docs/Documentation.md
+++ b/googletest/docs/Documentation.md
@ -12,5 +12,5 @@ the respective git branch/tag).**
 To contribute code to Google Test, read:
-  * [DevGuide](DevGuide.md) -- read this _before_ writing your first patch.
+  * [CONTRIBUTING](../CONTRIBUTING.md) -- read this _before_ writing your first patch.
  * [PumpManual](PumpManual.md) -- how we generate some of Google Test's source files.