[ceph.git] / ceph / src / rapidjson / thirdparty / gtest / googletest / docs / DevGuide.md



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](http://code.google.com/p/google-styleguide/) project.  All patches will be expected
to conform to the style outlined [here](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml).

## 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.

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