diff options
author | Alex Rønne Petersen <alex@lycus.org> | 2014-04-19 10:04:35 +0400 |
---|---|---|
committer | Alex Rønne Petersen <alex@lycus.org> | 2014-04-19 10:04:35 +0400 |
commit | 86c7d75bce6699a9085419e79d1435c3dbfa15ed (patch) | |
tree | 642e75a2b82d7cbe0bf9eb536fab525eb560d34e /CONTRIBUTING.md | |
parent | 29a2d0db57d105caf2da97811e6d832baa6099a1 (diff) |
Update CONTRIBUTING.md with info about pull request testing.
Diffstat (limited to 'CONTRIBUTING.md')
-rw-r--r-- | CONTRIBUTING.md | 44 |
1 files changed, 33 insertions, 11 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e0ff084549e..66dd3bd6952 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,4 +1,3 @@ - Guidelines ========== @@ -32,18 +31,41 @@ file in this directory. When contributing code, make sure that your contribution falls under the appropriate license. For example, contributions to code licensed -under MIT X11 code, should be MIT X11 code. +under MIT/X11 code, should be MIT/X11 code. -The Runtime is a special case. The code is dual licensed by Xamarin -under both the GNU LGPL v2 license and is also available under -commercial terms. For the runtime, you should either sign an +The runtime (`mono/...`) is a special case. The code is dual-licensed +by Xamarin under both the GNU LGPL v2 license and is also available +under commercial terms. For the runtime, you should either sign an agreement that grants Xamarin the rights to relicense your code under other licenses other than the LGPL v2 or your contribution must be -made as an MIT X11 license which grants us the same rights, but -involves no paperwork. +made as an MIT/X11 license which grants us the same rights, but +involves no paperwork. For the latter case, please specify on your +commit(s) that you are licensing the changes under MIT/X11. + +For other parts of the project that are dual-licensed, please state +on your commit(s) what license you are contributing the changes under. + +Testing +======= + +Pull requests go through testing on our [Jenkins server][2]. We will +usually only merge a pull request if it causes no regressions in a +test run there. + +When you submit a pull request, one of two things happens: + +* If you are a new contributor, Jenkins will ask for permissions (on + the pull request) to test it. A maintainer will reply to approve + the test run if they find the patch appropriate. After you have + submitted a few patches, a maintainer will whitelist you so that + all of your future pull requests are tested automatically. +* If you are a well-known, whitelisted contributor, Jenkins will go + ahead and test your pull request as soon as a test machine is + available. -Submitting Patches -================== +When your pull request has been built, Jenkins will update the build +status of your pull request. If it succeeded and we like the changes, +a maintainer will likely merge it. Otherwise, you can amend your pull +request to fix build breakage and Jenkins will test it again. -When Submitting patches to the dual-licensed portions, please specify -on the commit the license that the code is under. +[2] http://monojenkins.cloudapp.net |