提交 722484c4 编写于 作者: R rbrusu

Merge pull request #566 from taketwo/update-contributing-guide

Update contributing guide
...@@ -12,8 +12,8 @@ patches and features. ...@@ -12,8 +12,8 @@ patches and features.
## Using the issue tracker ## Using the issue tracker
The [issue tracker](https://github.com/PointCloudLibrary/pcl/issues) is The [issue tracker](https://github.com/PointCloudLibrary/pcl/issues) is
the preferred channel for [bug reports](#bugs) and the preferred channel for submitting [pull requests](#pull-requests) and
[submitting pull requests](#pull-requests), but please respect the following [bug reports](#bugs), but please respect the following
restrictions: restrictions:
* Please **do not** use the issue tracker for personal support requests (use * Please **do not** use the issue tracker for personal support requests (use
...@@ -23,6 +23,39 @@ restrictions: ...@@ -23,6 +23,39 @@ restrictions:
respect the opinions of others. respect the opinions of others.
<a name="pull-requests"></a>
## Pull requests
Good pull requests - patches, improvements, new features - are a fantastic
help. They should remain focused in scope and avoid containing unrelated
commits.
**Please ask first** before embarking on any significant pull request (e.g.
implementing features, refactoring code), otherwise you risk spending a lot of
time working on something that the project's developers might not want to merge
into the project. Please read the [tutorial on writing a new PCL class](http://pointclouds.org/documentation/tutorials/writing_new_classes.php#writing-new-classes) if you want to contribute a
brand new feature.
If you are new to Git, GitHub, or contributing to an open-source project, you
may want to consult the [step-by-step guide on preparing and submitting a pull request](https://github.com/PointCloudLibrary/pcl/wiki/A-step-by-step-guide-on-preparing-and-submitting-a-pull-request).
<a name="checklist"></a>
### Checklist
Please use the following checklist to make sure that your contribution is well
prepared for merging into PCL:
1. Source code adheres to the coding conventions described in [PCL Style Guide](http://pointclouds.org/documentation/advanced/pcl_style_guide.php).
But if you modify existing code, do not change/fix style in the lines that
are not related to your contribution.
2. Commit history is tidy (no merge commits, commits are [squashed](http://davidwalsh.name/squash-commits-git)
into logical units).
3. Each contributed file has a [license](#license) text on top.
<a name="bugs"></a> <a name="bugs"></a>
## Bug reports ## Bug reports
...@@ -62,109 +95,53 @@ Example: ...@@ -62,109 +95,53 @@ Example:
> merits). > merits).
<a name="pull-requests"></a> <a name="license"></a>
## Pull requests ## License
Good pull requests - patches, improvements, new features - are a fantastic PCL is 100% [BSD licensed](LICENSE.txt), and by submitting a patch, you agree to
help. They should remain focused in scope and avoid containing unrelated allow Open Perception, Inc. to license your work under the terms of the BSD
commits. License. The corpus of the license should be inserted as a C++ comment on top
of each `.h` and `.cpp` file:
**Please ask first** before embarking on any significant pull request (e.g.
implementing features, refactoring code), otherwise you risk spending a lot of ```cpp
time working on something that the project's developers might not want to merge /*
into the project. Please read the [tutorial on writing a new PCL class](http://pointclouds.org/documentation/tutorials/writing_new_classes.php#writing-new-classes) if you want to contribute a * Software License Agreement (BSD License)
brand new feature. *
* Point Cloud Library (PCL) - www.pointclouds.org
<a name="checklist"></a> * Copyright (c) 2014-, Open Perception, Inc.
### Checklist *
* All rights reserved.
Please use the following checklist to make sure that your contribution is well *
prepared for merging into PCL: * Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
1. Source code adheres to the coding conventions described in [PCL Style Guide](http://pointclouds.org/documentation/advanced/pcl_style_guide.php). * are met:
But if you modify existing code, do not change/fix style in the lines that *
are not related to your contribution. * * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
2. Commit history is tidy (no merge commits, commits are [squashed](http://davidwalsh.name/squash-commits-git) * * Redistributions in binary form must reproduce the above
into logical units). * copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials provided
3. Each contributed file has a [license](http://pointclouds.org/documentation/tutorials/writing_new_classes.php#licenses) text on top. * with the distribution.
* * Neither the name of the copyright holder(s) nor the names of its
### Suggested process * contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
Adhering to this process is the best way to get your work included in the *
project: * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
1. [Fork](http://help.github.com/fork-a-repo/) the project, clone your fork, * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
and configure the remotes: * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
* COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
```bash * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
# Clone your fork of the repo into the current directory * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
git clone https://github.com/<your-username>/pcl.git * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
# Navigate to the newly cloned directory * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
cd pcl * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
# Assign the original repo to a remote called "upstream" * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
git remote add upstream https://github.com/PointCloudLibrary/pcl.git * POSSIBILITY OF SUCH DAMAGE.
``` *
*/
2. If you cloned a while ago, get the latest changes from upstream: ```
```bash Please note that if the academic institution or company you are affiliated with
git checkout master does not allow to give up the rights, you may insert an additional copyright
git pull upstream master line.
```
3. Create a new topic branch (off the main project development branch) to
contain your feature, change, or fix:
```bash
git checkout -b <topic-branch-name>
```
4. Commit your changes in logical chunks. For any Git project, some good rules
for commit messages are
* the first line is commit summary, 50 characters or less,
* followed by an empty line
* followed by an explanation of the commit, wrapped to 72 characters.
See [a note about git commit messages](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
for more.
The first line of a commit message becomes the **title** of a pull request on
GitHub, like the subject line of an email. Including the key info in the
first line will help us respond faster to your pull.
If your pull request has multiple commits which revise the same lines of
code, it is better to [squash](http://davidwalsh.name/squash-commits-git)
those commits together into one logical unit.
But you don't always have to squash -- it is fine for a pull request to
contain multiple commits when there is a logical reason for the separation.
5. Locally merge (or rebase) the upstream development branch into your topic
branch:
```bash
git pull [--rebase] upstream master
```
6. Push your topic branch up to your fork:
```bash
git push origin <topic-branch-name>
```
7. [Open a Pull Request](https://help.github.com/articles/using-pull-requests/)
with a clear title and description.
8. After your Pull Request is away, you might want to get yourself back onto
`master` and delete the topic branch:
```bash
git checkout master
git branch -D <topic-branch-name>
```
**IMPORTANT**: By submitting a patch, you agree to allow the project owners to
license your work under the the terms of the [BSD License](LICENSE.txt).
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册