1 2 3If you are interested in understanding the internals of Google Mock, 4building from source, or contributing ideas or modifications to the 5project, then this document is for you. 6 7# Introduction # 8 9First, let's give you some background of the project. 10 11## Licensing ## 12 13All Google Mock source and pre-built packages are provided under the [New BSD License](http://www.opensource.org/licenses/bsd-license.php). 14 15## The Google Mock Community ## 16 17The Google Mock community exists primarily through the [discussion group](http://groups.google.com/group/googlemock), the 18[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 19discussion and you can also help us to keep the effectiveness of the 20group high by following and promoting the guidelines listed here. 21 22### Please Be Friendly ### 23 24Showing courtesy and respect to others is a vital part of the Google 25culture, and we strongly encourage everyone participating in Google 26Mock development to join us in accepting nothing less. Of course, 27being courteous is not the same as failing to constructively disagree 28with each other, but it does mean that we should be respectful of each 29other when enumerating the 42 technical reasons that a particular 30proposal may not be the best choice. There's never a reason to be 31antagonistic or dismissive toward anyone who is sincerely trying to 32contribute to a discussion. 33 34Sure, C++ testing is serious business and all that, but it's also 35a lot of fun. Let's keep it that way. Let's strive to be one of the 36friendliest communities in all of open source. 37 38### Where to Discuss Google Mock ### 39 40As 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 41code in order to sign up. Your participation itself is a valuable 42contribution. 43 44# Working with the Code # 45 46If you want to get your hands dirty with the code inside Google Mock, 47this is the section for you. 48 49## Checking Out the Source from Subversion ## 50 51Checking out the Google Mock source is most useful if you plan to 52tweak it yourself. You check out the source for Google Mock using a 53[Subversion](http://subversion.tigris.org/) client as you would for any 54other project hosted on Google Code. Please see the instruction on 55the [source code access page](../) for how to do it. 56 57## Compiling from Source ## 58 59Once you check out the code, you can find instructions on how to 60compile it in the [README](../README.md) file. 61 62## Testing ## 63 64A mocking framework is of no good if itself is not thoroughly tested. 65Tests should be written for any new code, and changes should be 66verified to not break existing tests before they are submitted for 67review. To perform the tests, follow the instructions in [README](http://code.google.com/p/googlemock/source/browse/trunk/README) and 68verify that there are no failures. 69 70# Contributing Code # 71 72We are excited that Google Mock is now open source, and hope to get 73great patches from the community. Before you fire up your favorite IDE 74and begin hammering away at that new feature, though, please take the 75time to read this section and understand the process. While it seems 76rigorous, we want to keep a high standard of quality in the code 77base. 78 79## Contributor License Agreements ## 80 81You must sign a Contributor License Agreement (CLA) before we can 82accept any code. The CLA protects you and us. 83 84 * 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). 85 * 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). 86 87Follow either of the two links above to access the appropriate CLA and 88instructions for how to sign and return it. 89 90## Coding Style ## 91 92To keep the source consistent, readable, diffable and easy to merge, 93we use a fairly rigid coding style, as defined by the [google-styleguide](https://github.com/google/styleguide) project. All patches will be expected 94to conform to the style outlined [here](https://github.com/google/styleguide/blob/gh-pages/cppguide.xml). 95 96## Submitting Patches ## 97 98Please do submit code. Here's what you need to do: 99 100 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. 101 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](http://code.google.com/p/googlemock/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. 102 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. 103 1. Ensure that your code adheres to the [Google Mock source code style](#Coding_Style.md). 104 1. Ensure that there are unit tests for your code. 105 1. Sign a Contributor License Agreement. 106 1. Create a patch file using `svn diff`. 107 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. 108 109## Google Mock Committers ## 110 111The current members of the Google Mock engineering team are the only 112committers at present. In the great tradition of eating one's own 113dogfood, we will be requiring each new Google Mock engineering team 114member to earn the right to become a committer by following the 115procedures in this document, writing consistently great code, and 116demonstrating repeatedly that he or she truly gets the zen of Google 117Mock. 118 119# Release Process # 120 121We follow the typical release process for Subversion-based projects: 122 123 1. A release branch named `release-X.Y` is created. 124 1. Bugs are fixed and features are added in trunk; those individual patches are merged into the release branch until it's stable. 125 1. An individual point release (the `Z` in `X.Y.Z`) is made by creating a tag from the branch. 126 1. Repeat steps 2 and 3 throughout one release cycle (as determined by features or time). 127 1. Go back to step 1 to create another release branch and so on. 128 129 130--- 131 132This 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/). 133