Spring/spring-integration
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add Contributor Covenant

Browse Source 
Also convert CONTRIBUTING from markdown to asciidoc.
This commit is contained in:
Gary Russell
2016-01-29 15:16:56 -05:00
committed by Artem Bilan
parent d2eba0927d
commit d91a6fd467
2 changed files with 161 additions and 83 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
CODE_OF_CONDUCT.adoc Normal file
View File

@@ -0,0 +1,44 @@
= Contributor Code of Conduct
As contributors and maintainers of this project, and in the interest of fostering an open
and welcoming community, we pledge to respect all people who contribute through reporting
issues, posting feature requests, updating documentation, submitting pull requests or
patches, and other activities.
We are committed to making participation in this project a harassment-free experience for
everyone, regardless of level of experience, gender, gender identity and expression,
sexual orientation, disability, personal appearance, body size, race, ethnicity, age,
religion, or nationality.
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery
* Personal attacks
* Trolling or insulting/derogatory comments
* Public or private harassment
* Publishing other's private information, such as physical or electronic addresses,
without explicit permission
* Other unethical or unprofessional conduct
Project maintainers have the right and responsibility to remove, edit, or reject comments,
commits, code, wiki edits, issues, and other contributions that are not aligned to this
Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors
that they deem inappropriate, threatening, offensive, or harmful.
By adopting this Code of Conduct, project maintainers commit themselves to fairly and
consistently applying these principles to every aspect of managing this project. Project
maintainers who do not follow or enforce the Code of Conduct may be permanently removed
from the project team.
This Code of Conduct applies both within project spaces and in public spaces when an
individual is representing the project or its community.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by
contacting a project maintainer at spring-code-of-conduct@pivotal.io . All complaints will
be reviewed and investigated and will result in a response that is deemed necessary and
appropriate to the circumstances. Maintainers are obligated to maintain confidentiality
with regard to the reporter of an incident.
This Code of Conduct is adapted from the
http://contributor-covenant.org[Contributor Covenant], version 1.3.0, available at
http://contributor-covenant.org/version/1/3/0/[contributor-covenant.org/version/1/3/0/]

200
CONTRIBUTING.md → CONTRIBUTING.adoc
View File

@@ -1,38 +1,47 @@
Contributor Guidelines
======================
= Spring Integration Contributor Guidelines
Have something you'd like to contribute to **Spring Integration**? We welcome pull requests, but ask that you carefully read this document first to understand how best to submit them; what kind of changes are likely to be accepted; and what to expect from the Spring team when evaluating your submission.
Have something you'd like to contribute to **Spring Integration**?
We welcome pull requests, but ask that you carefully read this document first to understand how best to submit them;
what kind of changes are likely to be accepted; and what to expect from the Spring team when evaluating your submission.
Please refer back to this document as a checklist before issuing any pull request; this will save time for everyone!
## Understand the basics
== Code of Conduct
This project adheres to the Contributor Covenant link:CODE_OF_CONDUCT.adoc[code of conduct].
By participating, you are expected to uphold this code. Please report unacceptable behavior to
spring-code-of-conduct@pivotal.io.
Not sure what a *pull request* is, or how to submit one? Take a look at GitHub's excellent [help documentation][] first.
== Understand the basics
## Search JIRA first; create an issue if necessary
Not sure what a *pull request* is, or how to submit one? Take a look at GitHub's excellent documentation:
https://help.github.com/articles/using-pull-requests/[Using Pull Requests] first.
Is there already an issue that addresses your concern? Do a bit of searching in our [JIRA issue tracker][] to see if you can find something similar. If not, please create a new issue before submitting a pull request unless the change is truly trivial, e.g. typo fixes, removing compiler warnings, etc.
== Search JIRA first; create an issue if necessary
## Sign the contributor license agreement
Is there already an issue that addresses your concern? Search the
https://jira.springsource.org/browse/INT[JIRA issue tracker] to see if you can find something similar.
If not, please create a new issue before submitting a pull request unless the change is truly trivial, e.g. typo fixes,
removing compiler warnings, etc.
== Sign the contributor license agreement
Very important, before we can accept any *Spring Integration contributions*, we will need you to sign the contributor license agreement (CLA). Signing the CLA does not grant anyone commit rights to the main repository, but it does mean that we can accept your contributions, and you will get an author credit if we do. In order to read and sign the CLA, please go to:
* [https://support.springsource.com/spring_committer_signup](https://support.springsource.com/spring_committer_signup)
* https://support.springsource.com/spring_committer_signup[Spring Committer Signup]
For **Project**, please select **Spring Integration**. The **Project Lead** is **Gary Russell**.
Once you've completed the web form, simply add the following in a comment on your pull request:
I have signed and agree to the terms of the SpringSource Individual
Contributor License Agreement.
I have signed and agree to the terms of the SpringSource Individual Contributor License Agreement.
## Fork the Repository
== Fork the Repository
1. Go to [https://github.com/spring-projects/spring-integration](https://github.com/spring-projects/spring-integration)
1. Go to https://github.com/spring-projects/spring-integration[https://github.com/spring-projects/spring-integration]
2. Hit the "fork" button and choose your own github account as the target
3. For more detail see [http://help.github.com/fork-a-repo/](http://help.github.com/fork-a-repo/)
3. For more detail see http://help.github.com/fork-a-repo/[Fork A Repo].
## Setup your Local Development Environment
== Setup your Local Development Environment
1. `git clone --recursive git@github.com:<your-github-username>/spring-integration.git`
2. `cd spring-integration`
@@ -45,24 +54,40 @@ _you should now see 'upstream' in addition to 'origin' where 'upstream' is the S
7. `git branch -a`
_you should see branches on origin as well as upstream, including 'master' and 'maint'_
## A Day in the Life of a Contributor
== A Day in the Life of a Contributor
* _Always_ work on topic branches (Typically use the Jira ticket ID as the branch name).
- For example, to create and switch to a new branch for issue INT-123: `git checkout -b INT-123`
* You might be working on several different topic branches at any given time, but when at a stopping point for one of those branches, commit (a local operation).
* Please follow the "Commit Guidelines" described in this chapter of Pro Git: [http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project](http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project)
* Then to begin working on another issue (say INT-101): `git checkout INT-101`. The _-b_ flag is not needed if that branch already exists in your local repository.
* When ready to resolve an issue or to collaborate with others, you can push your branch to origin (your fork), e.g.: `git push origin INT-123`
* If you want to collaborate with another contributor, have them fork your repository (add it as a remote) and `git fetch <your-username>` to grab your branch. Alternatively, they can use `git fetch --all` to sync their local state with all of their remotes.
* Please follow the "Commit Guidelines" described in
http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project[this chapter of Pro Git].
* Then to begin working on another issue (say INT-101): `git checkout INT-101`. The _-b_ flag is not needed if that
branch already exists in your local repository.
* When ready to resolve an issue or to collaborate with others, you can push your branch to origin (your fork),
e.g.: `git push origin INT-123`
* If you want to collaborate with another contributor, have them fork your repository (add it as a remote) and
`git fetch <your-username>` to grab your branch.
Alternatively, they can use `git fetch --all` to sync their local state with all of their remotes.
* If you grant that collaborator push access to your repository, they can even apply their changes to your branch.
* When ready for your contribution to be reviewed for potential inclusion in the master branch of the canonical spring-integration repository (what you know as 'upstream'), issue a pull request to the SpringSource repository (for more detail, see [http://help.github.com/send-pull-requests/](http://help.github.com/send-pull-requests/)).
* The project lead may merge your changes into the upstream master branch as-is, he may keep the pull request open yet add a comment about something that should be modified, or he might reject the pull request by closing it.
* A prerequisite for any pull request is that it will be cleanly merge-able with the upstream master's current state. **This is the responsibility of any contributor.** If your pull request cannot be applied cleanly, the project lead will most likely add a comment requesting that you make it merge-able. For a full explanation, see the Pro Git section on rebasing: [http://git-scm.com/book/en/Git-Branching-Rebasing](http://git-scm.com/book/en/Git-Branching-Rebasing). As stated there: "> Often, you’ll do this to make sure your commits apply cleanly on a remote branch — perhaps in a project to which you’re trying to contribute but that you don’t maintain."
* When ready for your contribution to be reviewed for potential inclusion in the master branch of the canonical
spring-integration repository (what you know as 'upstream'), issue a pull request to the SpringSource repository
(for more detail, see https://help.github.com/articles/using-pull-requests/[Using pull requests]).
* The project lead may merge your changes into the upstream master branch as-is, he may keep the pull request open yet
add a comment about something that should be modified, or he might reject the pull request by closing it.
* A prerequisite for any pull request is that it will be cleanly merge-able with the upstream master's current state.
**This is the responsibility of any contributor.**
If your pull request cannot be applied cleanly, the project lead will most likely add a comment requesting that you make
it merge-able.
For a full explanation, see http://git-scm.com/book/en/Git-Branching-Rebasing[the Pro Git section on rebasing].
As stated there: _"> Often, you’ll do this to make sure your commits apply cleanly on a remote branch — perhaps in a
project to which you’re trying to contribute but that you don’t maintain."_
## Keeping your Local Code in Sync
* As mentioned above, you should always work on topic branches (since 'master' is a moving target). However, you do want to always keep your own 'origin' master branch in synch with the 'upstream' master.
== Keeping your Local Code in Sync
* As mentioned above, you should always work on topic branches (since 'master' is a moving target). However, you do want
to always keep your own 'origin' master branch in synch with the 'upstream' master.
* Within your local working directory, you can sync up all remotes' branches with: `git fetch --all`
* While on your own local master branch: `git pull upstream master` (which is the equivalent of fetching upstream/master and merging that into the branch you are in currently)
* While on your own local master branch: `git pull upstream master` (which is the equivalent of fetching upstream/master
and merging that into the branch you are in currently)
* Now that you're in synch, switch to the topic branch where you plan to work, e.g.: `git checkout -b INT-123`
* When you get to a stopping point: `git commit`
* If changes have occurred on the upstream/master while you were working you can synch again:
@@ -70,49 +95,52 @@ _you should see branches on origin as well as upstream, including 'master' and '
- Then: `git pull upstream master`
- Switch back to the topic branch: `git checkout INT-123` (no -b needed since the branch already exists)
- Rebase the topic branch to minimize the distance between it and your recently synched master branch: `git rebase master`
(Again, for more detail see the Pro Git section on rebasing: [http://git-scm.com/book/en/Git-Branching-Rebasing](http://git-scm.com/book/en/Git-Branching-Rebasing))
* **Note** You cannot rebase if you have already pushed your branch to your remote because you'd be rewriting history (see **'The Perils of Rebasing'** in the article). If you rebase by mistake, you can undo it as discussed [in this stackoverflow discussion](http://stackoverflow.com/questions/134882/undoing-a-git-rebase). Once you have published your branch, you need to merge in the master rather than rebasing.
* Now, if you issue a pull request, it is much more likely to be merged without conflicts. Most likely, any pull request that would produce conflicts will be deferred until the issuer of that pull request makes these adjustments.
* Assuming your pull request is merged into the 'upstream' master, you will actually end up pulling that change into your own master eventually, and at that time, you may decide to delete the topic branch from your local repository and your fork (origin) if you pushed it there.
(Again, for more detail see http://git-scm.com/book/en/Git-Branching-Rebasing[the Pro Git section on rebasing]).
* **Note** You cannot rebase if you have already pushed your branch to your remote because you'd be rewriting history
(see **'The Perils of Rebasing'** in the article).
If you rebase by mistake, you can undo it as discussed
http://stackoverflow.com/questions/134882/undoing-a-git-rebase[in this stackoverflow discussion].
Once you have published your branch, you need to merge in the master rather than rebasing.
* Now, if you issue a pull request, it is much more likely to be merged without conflicts.
Most likely, any pull request that would produce conflicts will be deferred until the issuer of that pull request makes
these adjustments.
* Assuming your pull request is merged into the 'upstream' master, you will actually end up pulling that change into
your own master eventually, and at that time, you may decide to delete the topic branch from your local repository and
your fork (origin) if you pushed it there.
- to delete the local branch: `git branch -d INT-123`
- to delete the branch from your origin: `git push origin :INT-123`
## Maintain a linear commit history
== Maintain a linear commit history
When issuing pull requests, please ensure that your commit history is linear. From the command line you can check this using:
When merging to master, the project __always__ uses fast-forward merges.
When issuing pull requests, please ensure that your commit history is linear.
From the command line you can check this using:
````
----
log --graph --pretty=oneline
````
----
As this may cause lots of typing, we recommend creating a global alias, e.g. `git logg` for this:
````
----
git config --global alias.logg 'log --graph --pretty=oneline'
````
----
This command, will provide the following output, which in this case shows a nice linear history:
````
----
* c129a02e6c752b49bacd4a445092a44f66c2a1e9 INT-2721 Increase Timers on JDBC Delayer Tests
* 14e556ce23d49229c420632cef608630b1d82e7d INT-2620 Fix Debug Log
* af35733b20fa97a5df123a155362f9b5781ac4b6 Merge pull request #814 from willschipp/INT-3037
|\
| * 6140aa7b2cfb6ae309c55a157e94b44e5d0bea4f INT-3037 Fix JDBC MS Discard After Completion
|/
* 6140aa7b2cfb6ae309c55a157e94b44e5d0bea4f INT-3037 Fix JDBC MS Discard After Completion
* 077f2b24ea871a3937c513e08241d1c6cb9c9179 Update Spring Social Twitter to 1.0.5
* cc5bcf64a68bb7b6e59132cc675c36be694e174a Merge pull request #819 from garyrussell/INT-3053
|\
| * 6d4f2b46d859c903881a561c35aa28df68f8faf3 INT-3053 Allow task-executor on <reply-listener/>
|/
* 1a27d8194158572f59622f1618de17b99dfb52f0 Merge pull request #816 from habuma
|\
| * 56f9581b85a8a40bbcf2461ffc0753212669a68d Update Spring Social Twitter version to 1.0.4
|/
````
If you see intersecting lines, that usually means that you forgot to rebase you branch. As mentioned earlier, **please rebase against master** before issueing a pull request.
* 6d4f2b46d859c903881a561c35aa28df68f8faf3 INT-3053 Allow task-executor on <reply-listener/>
* 56f9581b85a8a40bbcf2461ffc0753212669a68d Update Spring Social Twitter version to 1.0.4
----
## Mind the whitespace
If you see intersecting lines, that usually means that you forgot to rebase you branch.
As mentioned earlier, **please rebase against master** before issuing a pull request.
== Mind the whitespace
Please carefully follow the whitespace and formatting conventions already present in the framework.
@@ -120,7 +148,7 @@ Please carefully follow the whitespace and formatting conventions already presen
2. Unix (LF), not DOS (CRLF) line endings
3. Eliminate all trailing whitespace
4. Wrap Javadoc at 90 characters
5. Aim to wrap code at 90 characters, but favor readability over wrapping
5. Aim to wrap code at 120 characters, but favor readability over wrapping
6. Preserve existing formatting; i.e. do not reformat code for its own sake
7. Search the codebase using `git grep` and other tools to discover common
naming conventions, etc.
@@ -129,9 +157,10 @@ Please carefully follow the whitespace and formatting conventions already presen
## Add Apache license header to all new classes
```java
[source, java]
----
/*
* Copyright 2013 the original author or authors.
* Copyright 2016 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -147,27 +176,31 @@ Please carefully follow the whitespace and formatting conventions already presen
*/
package ...;
```
----
## Update license header to modified files as necessary
== Update license header to modified files as necessary
Always check the date range in the Apache license header. For example, if you've modified a file in 2013 whose header still reads
Always check the date range in the Apache license header. For example, if you've modified a file in 2016 whose header
still reads
```java
[source java]
----
* Copyright 2002-2011 the original author or authors.
```
----
then be sure to update it to 2013 appropriately
then be sure to update it to 2016 appropriately
```java
* Copyright 2002-2013 the original author or authors.
```
[source java]
----
* Copyright 2002-2016 the original author or authors.
----
## Use @since tags
== Use @since tags
Use @since tags for newly-added public API types and methods e.g.
```java
[source java]
----
/**
* ...
*
@@ -175,17 +208,18 @@ Use @since tags for newly-added public API types and methods e.g.
* @since 3.0
* @see ...
*/
```
----
## Submit JUnit test cases for all behavior changes
== Submit JUnit test cases for all behavior changes
Search the codebase to find related unit tests and add additional @Test methods within. It is also acceptable to submit test cases on a per JIRA issue basis.
## Squash commits
== Squash commits
Use `git rebase --interactive`, `git add --patch` and other tools to "squash" multiple commits into atomic changes. In addition to the man pages for git, there are many resources online to help you understand how these tools work. Here is one: http://book.git-scm.com/4_interactive_rebasing.html.
Use `git rebase --interactive`, `git add --patch` and other tools to "squash" multiple commits into atomic changes.
In addition to the man pages for git, there are many resources online to help you understand how these tools work.
## Use your real name in git commits
== Use your real name in git commits
Please configure git to use your real first and last name for any commits you intend to submit as pull requests. For example, this is not acceptable:
@@ -208,30 +242,30 @@ or locally for the *spring-integration* repository only by omitting the '--globa
git config user.name "First Last"
git config user.email user@mail.com
## Run all tests prior to submission
== Run all tests prior to submission
See the [checking out and building][] section of the README for instructions. Make sure that all tests pass prior to submitting your pull request.
See the https://github.com/spring-projects/spring-integration#checking-out-and-building[checking out and building]
section of the README for instructions.
Make sure that all tests pass prior to submitting your pull request.
## Mention your pull request on the associated JIRA issue
== Mention your pull request on the associated JIRA issue
Add a comment to the associated JIRA issue(s) linking to your new pull request.
## Provide a Link to the JIRA issue in the Associated Pull Request
== Provide a Link to the JIRA issue in the Associated Pull Request
Add a JIRA issue link to your first commit comment of the pull request on the last line, so your commit message may looks like this:
Add a JIRA issue link to your first commit comment of the pull request on the last line, so your commit message
may look like this:
----
INT-1639: Add <spel-function> support
JIRA: https://jira.springsource.org/browse/INT-1639
* add `<spel-function>` XSD element
* add `SpelFunctionParser`
* add `SpelFunctionRegistrar` to avoid introducing some confused 'Method'-bean
* add `SpelFunctionRegistrar` collaboration with `IntegrationEvaluationContextFactoryBean`
* some refactoring for `IntegrationEvaluationContextFactoryBean`
* polishing some failed tests after this change
[help documentation]: http://help.github.com/send-pull-requests
[JIRA issue tracker]: https://jira.springsource.org/browse/INT
[checking out and building]: https://github.com/spring-projects/spring-integration#checking-out-and-building
----