X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=CONTRIBUTING.md;h=ed8d6fe7cc5ac74d975dfc69afdd0d3de2abf69b;hb=e4f1b8c13d59c69ac213a2db3cb28c3e08fff297;hp=e0ff084549ee73fec715b3e4a7e408a94aee1fa5;hpb=e946a6cdebde729e1c03ec374184254ab38da184;p=mono.git diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e0ff084549e..ed8d6fe7cc5 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,4 +1,3 @@ - Guidelines ========== @@ -6,7 +5,7 @@ When contributing to the Mono project, please follow the [Mono Coding Guidelines][1]. We have been using a coding style for many years, please make your patches conform to these guidelines. -[1] http://www.mono-project.com/Coding_Guidelines +[1]: http://www.mono-project.com/community/contributing/coding-guidelines/ Etiquette ========= @@ -22,28 +21,53 @@ investigate bugs, regressions and problems. License ======= -The Mono project uses the MIT X11, GNU LGPL version 2 and the Apache -License 2.0. We also imported some Microsoft code licensed under the -open source Microsoft Public License. +The Mono runtime, compilers, and tools and most of the class libraries +are licensed under the MIT license. But include some bits of code +licensed under different licenses. The exact list is [available here] (https://github.com/mono/mono/blob/master/LICENSE). Different parts of Mono use different licenses. The actual details of which licenses are used for which parts are detailed on the LICENSE 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. +CLA +======= + +Contributions are now taken under the [.NET Foundation CLA] (https://cla2.dotnetfoundation.org/). + +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. + +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. + +[2]: http://jenkins.mono-project.com/ -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 -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. +# Inactivity -Submitting Patches -================== +Occasionally, a pull request sits for several months without any +response from the author. This isn't necessarily an issue, but we may +sometimes decide to close pull requests that have not seen any +progress for a long time. This is in interest of keeping the pull +request list clean so that other pull requests don't get lost in the +clutter. -When Submitting patches to the dual-licensed portions, please specify -on the commit the license that the code is under. +If we do close your pull request due to inactivity, you're more than +welcome to submit it anew after you address any comments or issues that +were brought up on the original pull request.