diff options
author | Billy Donahue <BillyDonahue@users.noreply.github.com> | 2015-10-08 13:32:40 (GMT) |
---|---|---|
committer | Billy Donahue <BillyDonahue@users.noreply.github.com> | 2015-10-08 13:32:40 (GMT) |
commit | 554ca00ff7067fed06f17f101a417a65145ccae7 (patch) | |
tree | 5515287b25c0a80ca0d9d55938bc599326bb0e53 /googletest | |
parent | 7f4448f40b3f3f16a75787c016139511579367ed (diff) | |
download | googletest-554ca00ff7067fed06f17f101a417a65145ccae7.zip googletest-554ca00ff7067fed06f17f101a417a65145ccae7.tar.gz googletest-554ca00ff7067fed06f17f101a417a65145ccae7.tar.bz2 |
Update DevGuide.mdrefs/pull/607/head
stop talking about subversion in the devguide.
Diffstat (limited to 'googletest')
-rw-r--r-- | googletest/docs/DevGuide.md | 37 |
1 files changed, 12 insertions, 25 deletions
diff --git a/googletest/docs/DevGuide.md b/googletest/docs/DevGuide.md index 867770a..06467a3 100644 --- a/googletest/docs/DevGuide.md +++ b/googletest/docs/DevGuide.md @@ -14,8 +14,8 @@ All Google Test source and pre-built packages are provided under the [New BSD Li ## The Google Test Community ## -The Google Test community exists primarily through the [discussion group](http://groups.google.com/group/googletestframework), the -[issue tracker](http://code.google.com/p/googletest/issues/list) and, to a lesser extent, the [source control repository](http://code.google.com/p/googletest/source/checkout). You are definitely encouraged to contribute to the +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. @@ -35,37 +35,27 @@ 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 Test ### - -As always, discuss Google Test in the official [Google C++ Testing Framework discussion group](http://groups.google.com/group/googletestframework). You don't have to actually submit -code in order to sign up. Your participation itself is a valuable -contribution. +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. -## Checking Out the Source from Subversion ## - -Checking out the Google Test source is most useful if you plan to -tweak it yourself. You check out the source for Google Test 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](http://code.google.com/p/googletest/source/checkout) 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](http://code.google.com/p/googletest/source/browse/trunk/README) file. +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](http://code.google.com/p/googletest/source/browse/trunk/README) and -verify that there are no failures. +review. To perform the tests, follow the instructions in +[README](../README.md) and verify that there are no failures. # Contributing Code # @@ -104,14 +94,12 @@ can read the PumpManual for details. 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 Test issue tracker](http://code.google.com/p/googletest/issues/list). 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. 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 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](http://code.google.com/p/rietveld/wiki/CodeReviewHelp). When you are ready, upload your patch via Rietveld and notify `googletestframework@googlegroups.com` to review it. There are several ways to upload the patch. We recommend using the [upload\_gtest.py](http://code.google.com/p/googletest/source/browse/trunk/scripts/upload_gtest.py) script, which you can find in the `scripts/` folder in the SVN trunk. + 1. Create a Pull Request in the usual way. ## Google Test Committers ## @@ -125,7 +113,7 @@ Test. # Release Process # -We follow the typical release process for Subversion-based projects: +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. @@ -133,7 +121,6 @@ We follow the typical release process for Subversion-based projects: 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/).
\ No newline at end of file +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/). |