OpenE2K
/
rust
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

auto merge of #6952 : artagnon/rust/contributing-wrap, r=bstrie 

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
This commit is contained in:
bors 2013-06-05 08:55:50 -07:00
parent de3000af8f 4936421031
commit 38b1d60e0d
1 changed files with 31 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
CONTRIBUTING.md
View File

@ -1,27 +1,42 @@
## Pull request procedure
Pull requests should be targeted at Rust's `incoming` branch (note that by default Github will aim them at the `master` branch) --
see "Changing The Commit Range and Destination Repository" in Github's documentation on [pull requests](https://help.github.com/articles/using-pull-requests).
Before pushing to your Github repo and issuing the pull request, please do two things:
Pull requests should be targeted at Rust's `incoming` branch (note
that by default Github will aim them at the `master` branch) -- see
"Changing The Commit Range and Destination Repository" in Github's
documentation on [pull
requests](https://help.github.com/articles/using-pull-requests).
Before pushing to your Github repo and issuing the pull request,
please do two things:
1. [Rebase](http://git-scm.com/book/en/Git-Branching-Rebasing) your local changes against the `incoming` branch. Resolve any conflicts that arise.
2. Run the full Rust test suite with the `make check` command.
You're not off the hook even if you just stick to documentation; code examples in the docs are tested as well!
1. [Rebase](http://git-scm.com/book/en/Git-Branching-Rebasing) your
local changes against the `incoming` branch. Resolve any conflicts
that arise.
Pull requests will be treated as "review requests",
and we will give feedback we expect to see corrected on [style](https://github.com/mozilla/rust/wiki/Note-style-guide) and substance before pulling.
Changes contributed via pull request should focus on a single issue at a time, like any other.
We will not accept pull-requests that try to "sneak" unrelated changes in.
2. Run the full Rust test suite with the `make check` command. You're
not off the hook even if you just stick to documentation; code
examples in the docs are tested as well!
Normally, all pull requests must include regression tests (see [Note-testsuite](https://github.com/mozilla/rust/wiki/Note-testsuite)) that test your change.
Occasionally, a change will be very difficult to test for.
In those cases, please include a note in your commit message explaining why.
Pull requests will be treated as "review requests", and we will give
feedback we expect to see corrected on
[style](https://github.com/mozilla/rust/wiki/Note-style-guide) and
substance before pulling. Changes contributed via pull request should
focus on a single issue at a time, like any other. We will not accept
pull-requests that try to "sneak" unrelated changes in.
In the licensing header at the beginning of any files you change, please make sure the listed date range includes the current year.
For example, if it's 2013, and you change a Rust file that was created in 2010, it should begin:
Normally, all pull requests must include regression tests (see
[Note-testsuite](https://github.com/mozilla/rust/wiki/Note-testsuite))
that test your change. Occasionally, a change will be very difficult
to test for. In those cases, please include a note in your commit
message explaining why.
In the licensing header at the beginning of any files you change,
please make sure the listed date range includes the current year. For
example, if it's 2013, and you change a Rust file that was created in
2010, it should begin:
```
// Copyright 2010-2013 The Rust Project Developers.
```
For more details, please refer to [Note-development-policy](https://github.com/mozilla/rust/wiki/Note-development-policy).
For more details, please refer to
[Note-development-policy](https://github.com/mozilla/rust/wiki/Note-development-policy).