jetty-documentation/src/main/asciidoc/reference/contributing/patches.adoc - jetty - Git at Google

 //  ========================================================================
 //  Copyright (c) 1995-2017 Mort Bay Consulting Pty. Ltd.
 //  ========================================================================
 //  All rights reserved. This program and the accompanying materials
 //  are made available under the terms of the Eclipse Public License v1.0
 //  and Apache License v2.0 which accompanies this distribution.
 //
 //      The Eclipse Public License is available at
 //      http://www.eclipse.org/legal/epl-v10.html
 //
 //      The Apache License v2.0 is available at
 //      http://www.opensource.org/licenses/apache2.0.php
 //
 //  You may elect to redistribute this code under either of these licenses.
 //  ========================================================================

 [[contributing-patches]]
 === Contributing Patches

 We love seeing people contribute patches to the Jetty project and the process is relatively simple.
 The requirements to commit are modest but very important to the Eclipse Foundation and the intellectual property of the open source project.
 The following is the general process by which we operate.

 * You must have a signed Eclipse Contributor Agreement.
 * This agreement must be under the _same_ email address as the Git pull request originates from.
 * The commit must be signed.
 * When the pull request is made, a git-hook will validate the email address.
 ** If the result is a green checkbox then the Jetty committers can review the pull request.
 ** If the result is a red X then there is absolutely nothing the Jetty committers can do to accept the commit at this point.
 * This may not be the final form a commit will take, there may be some back and forth and you may be asked to re-issue a pull request.


 Not everything is specifically relevant since we are at GitHub but the crux of things are detailed there.  The CLA is critically important to the process.

 [[contributing-cla]]
 ==== Sign a CLA

 The Eclipse Foundation has a strong Intellectual Property policy which tracks contributions in detail to ensure that:

 1.  Did the contributor author 100% of the content?
 2.  Does the contributor have the rights to contribute this content to Eclipse?
 3.  Is the contribution under the project’s license(s) (e.g. EPL)

 A contributor needs to e-sign a Contributor Licence Agreement (for more explanation see the http://www.eclipse.org/legal/clafaq.php[Eclipse CLA FAQ] ) regardless of how their contribution patch is provided.
 You can familiarize yourself with the Eclipse wiki page at http://wiki.eclipse.org/Development_Resources/Contributing_via_Git[Contributing via Git].
 In order to have a pull request accepted by any Eclipse project you must complete this agreement.
 ____
 [TIP]
 Log into the https://projects.eclipse.org/user/login/sso[Eclipse projects forge] (you will need to create an account with the Eclipse Foundation if you have not already done so); click on "Contributor License Agreement"; and Complete the form.
 Be sure to use the _same email address_ when you create any Git commit records.
 ____

 [[contributing-git-config]]
 ==== Configuring Git

 GitHub has copious amounts of quality documentation on how to interact with the system and you will minimally need to configure the user.email property.
 Check out the following link:https://help.github.com/articles/setting-your-email-in-git[guide on GitHub] for more information.

 [[contributing-making-the-commit]]
 ==== Making the Commit

 When making the commit for the pull request it is  _vital_ that you "sign-off" on the commit using "git commit -s" option.
 Without this sign-off, your patch cannot be applied to the Jetty repository because it will be rejected.

 You can check out the link:https://help.github.com/articles/signing-tags-using-gpg[guide at Github] for more information.
 ____
 [TIP]
 One way to think of this is that when you sign the CLA you are indicating that you are free to contribute to eclipse, but that doesn't mean everything you ever do can be contributed.
 Using the commit signing mechanism indicates that your commit is under the auspices of your agreement.
 ____

 If a pull request is for a particular issue in our repository then the format of the commit message is important.
 The message should follow the form "Issue #123 <description of the commit>".
 When the Jetty project runs releases we have an automated process that scans for commits with this format for inclusion in our VERSION.txt file.

 ____
 > git commit -s -m "Issue #123 resolving the issue by adding widget"
 ____

 [[contributing-the-pull-request]]
 ==== The Pull Request

 Pull requests are very much a GitHub process so best link:https://help.github.com/articles/creating-a-pull-request[explained by Github].

 [[contributing-our-policies]]
 ==== Our Policies

 We wholeheartedly welcome contributions to Jetty and will do our best to process them in a timely fashion.
 While not every contribution will be accepted as is our commitment is to work with interested parties on the things they care about.
 With that in mind, short of some simple contributions we can only handle pull requests with actively engaged parties.
 We reserve the right to abandon pull requests whose authors do no respond in a timely fashion.
 We will generally adhere to the following time frames for contributions.

 * Invalid Pull Requests - 1 week
 ** These pull requests do not follow the contribution requirements for some reason, be it missing contributor agreement or the wrong email.
 ** We will try and follow up with the pull request author to resolve the issue but much of this is out of our hands and are between committer and the Eclipse Foundation.
 ** If we do not hear from the contributor after a week we will close the pull request.

 * Valid Pull Requests - 2 weeks
 ** These pull requests have a green check mark after the commit title.
 ** If the pull request can be immediately applied we will do so.
 ** There may need to be some conversation on the issue in which case a committer will follow up with the author in the pull request.
 ** If the original contributor does not respond within 2 weeks we may close the commit.
 ** If we see value in the commit yet the author has not responded after 2 weeks we may make some variation of the commit ourselves.
	// ========================================================================
	// Copyright (c) 1995-2017 Mort Bay Consulting Pty. Ltd.
	// ========================================================================
	// All rights reserved. This program and the accompanying materials
	// are made available under the terms of the Eclipse Public License v1.0
	// and Apache License v2.0 which accompanies this distribution.
	//
	// The Eclipse Public License is available at
	// http://www.eclipse.org/legal/epl-v10.html
	//
	// The Apache License v2.0 is available at
	// http://www.opensource.org/licenses/apache2.0.php
	//
	// You may elect to redistribute this code under either of these licenses.
	// ========================================================================

	[[contributing-patches]]
	=== Contributing Patches

	We love seeing people contribute patches to the Jetty project and the process is relatively simple.
	The requirements to commit are modest but very important to the Eclipse Foundation and the intellectual property of the open source project.
	The following is the general process by which we operate.

	* You must have a signed Eclipse Contributor Agreement.
	* This agreement must be under the _same_ email address as the Git pull request originates from.
	* The commit must be signed.
	* When the pull request is made, a git-hook will validate the email address.
	** If the result is a green checkbox then the Jetty committers can review the pull request.
	** If the result is a red X then there is absolutely nothing the Jetty committers can do to accept the commit at this point.
	* This may not be the final form a commit will take, there may be some back and forth and you may be asked to re-issue a pull request.



	Not everything is specifically relevant since we are at GitHub but the crux of things are detailed there. The CLA is critically important to the process.

	[[contributing-cla]]
	==== Sign a CLA

	The Eclipse Foundation has a strong Intellectual Property policy which tracks contributions in detail to ensure that:

	1. Did the contributor author 100% of the content?
	2. Does the contributor have the rights to contribute this content to Eclipse?
	3. Is the contribution under the project’s license(s) (e.g. EPL)

	A contributor needs to e-sign a Contributor Licence Agreement (for more explanation see the http://www.eclipse.org/legal/clafaq.php[Eclipse CLA FAQ] ) regardless of how their contribution patch is provided.
	You can familiarize yourself with the Eclipse wiki page at http://wiki.eclipse.org/Development_Resources/Contributing_via_Git[Contributing via Git].
	In order to have a pull request accepted by any Eclipse project you must complete this agreement.
	____
	[TIP]
	Log into the https://projects.eclipse.org/user/login/sso[Eclipse projects forge] (you will need to create an account with the Eclipse Foundation if you have not already done so); click on "Contributor License Agreement"; and Complete the form.
	Be sure to use the _same email address_ when you create any Git commit records.
	____

	[[contributing-git-config]]
	==== Configuring Git

	GitHub has copious amounts of quality documentation on how to interact with the system and you will minimally need to configure the user.email property.
	Check out the following link:https://help.github.com/articles/setting-your-email-in-git[guide on GitHub] for more information.

	[[contributing-making-the-commit]]
	==== Making the Commit

	When making the commit for the pull request it is _vital_ that you "sign-off" on the commit using "git commit -s" option.
	Without this sign-off, your patch cannot be applied to the Jetty repository because it will be rejected.

	You can check out the link:https://help.github.com/articles/signing-tags-using-gpg[guide at Github] for more information.
	____
	[TIP]
	One way to think of this is that when you sign the CLA you are indicating that you are free to contribute to eclipse, but that doesn't mean everything you ever do can be contributed.
	Using the commit signing mechanism indicates that your commit is under the auspices of your agreement.
	____

	If a pull request is for a particular issue in our repository then the format of the commit message is important.
	The message should follow the form "Issue #123 <description of the commit>".
	When the Jetty project runs releases we have an automated process that scans for commits with this format for inclusion in our VERSION.txt file.

	____
	> git commit -s -m "Issue #123 resolving the issue by adding widget"
	____

	[[contributing-the-pull-request]]
	==== The Pull Request

	Pull requests are very much a GitHub process so best link:https://help.github.com/articles/creating-a-pull-request[explained by Github].

	[[contributing-our-policies]]
	==== Our Policies

	We wholeheartedly welcome contributions to Jetty and will do our best to process them in a timely fashion.
	While not every contribution will be accepted as is our commitment is to work with interested parties on the things they care about.
	With that in mind, short of some simple contributions we can only handle pull requests with actively engaged parties.
	We reserve the right to abandon pull requests whose authors do no respond in a timely fashion.
	We will generally adhere to the following time frames for contributions.

	* Invalid Pull Requests - 1 week
	** These pull requests do not follow the contribution requirements for some reason, be it missing contributor agreement or the wrong email.
	** We will try and follow up with the pull request author to resolve the issue but much of this is out of our hands and are between committer and the Eclipse Foundation.
	** If we do not hear from the contributor after a week we will close the pull request.

	* Valid Pull Requests - 2 weeks
	** These pull requests have a green check mark after the commit title.
	** If the pull request can be immediately applied we will do so.
	** There may need to be some conversation on the issue in which case a committer will follow up with the author in the pull request.
	** If the original contributor does not respond within 2 weeks we may close the commit.
	** If we see value in the commit yet the author has not responded after 2 weeks we may make some variation of the commit ourselves.