From e93ca409ae0d7cd6489c66f696ad564c77bcb6a2 Mon Sep 17 00:00:00 2001 From: Seth Tisue Date: Mon, 13 Jul 2015 18:57:45 -0400 Subject: drop in pull request policy from old wiki --- CONTRIBUTING.md | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e6e0e0b923..d7705512a3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -54,3 +54,68 @@ A new language feature requires a SIP (Scala Improvement Process) proposal. For - [Boy Scout Rule](http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule) should be applied. Please also have a look at our [Pull Request Policy](https://github.com/scala/scala/wiki/Pull-Request-Policy), as well as the [Scala Hacker Guide](http://www.scala-lang.org/contribute/hacker-guide.html) by @xeno-by. + + +# Pull Request Policy + +taken from https://github.com/scala/scala/wiki/Pull-Request-Policy +before it was put out of its misery + +Hi there, pull request submitter! + +Your pull request should: + - (... have been discussed on scala-internals) + - merge cleanly + - consist of commits with messages that clearly state which problem this commit resolves and how + - it should be stated in the active, present tense + - its subject should be 60 characters or less + - [conventions](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) + - for a bug fix, the title must look like "SI-NNNN - don't crash when moon is in wrong phase" + - overall, think of the first line of the commit as a description of the action performed by the commit on the code base, so use the present tense -- that also makes them easy to reuse in release notes + - backports should be tagged as [backport], it's also nice to mention this when a commit purely refactors and is not intended to change behaviour + - when working on maintenance branches (e.g., 2.10.x), include [nomerge] if this commit should not be merged forward into the next release branch + - come with tests (included in the same commit as the functional change), or explain in detail why it cannot be tested (discuss this on scala-internals first). The tests itself should: + - be minimal, deterministic, stable (unaffected by irrelevant changes), easy to understand and review + - have minimal dependencies: a compiler bug should not depend on, e.g. the Scala library + - typically fail before your fix is applied (so we see that you are fixing a legitimate bug) and should obviously pass after your fix + - come with appropriate documentation + - for example, any API additions should include Scaladoc + - each commit must pass the test suite (checked automatically by the build bot by running approximately `ant test-opt`) + - a commit is considered a unit of useful change and must thus pass the test suite + (this way we stand a chance running git bisect later) + - be assigned to one or more reviewers (if you're not sure, see the list below or contact scala-internals) + - to assign a reviewer, add a "review by @reviewer" to your PR description. NOTE: it's best not to @mention in commit messages, as github pings you every time a commit with your @name on it shuffles through the system (even in other repos, on merges,...) + - get the green light from the reviewer ("LGTM" -- looks good to me) + - review feedback may be addressed by pushing new commits to the request, + if these commits stand on their own + +Once all these conditions are met, and we agree with the change +(we are available on scala-internals to discuss this beforehand), +we will merge your changes. + +Please note: you are responsible for meeting these criteria (reminding your reviewer, for example). + +### Pull request bot mechanics +* The build bot automatically builds commits as they appear in a PR. Click on the little x next to a commit sha to go to the overview of the PR validation job. To diagnose a failure, consult the console output of the job that failed. + * 'PLS REBUILD ALL' will force the bot to rebuild (only necessary when a spurious failure occurred -- i.e., you expect a different validation outcome without changing the commit shas that make up the PR) + +### List of reviewers by area: + +* library: @phaller (Philipp Haller), @axel22 (Aleksander Prokopec -- concurrent & collection) +* specialisation: @axel22 (Aleksander Prokopec), @vladureche (Vlad Ureche), @dragos (Iulian Dragos) +* named / default args, annotations, plugins: @lrytz (Lukas Rytz) +* macros, reflection, manifests, string interpolation: @xeno-by (Eugene Burmako), @cvogt (Christopher Vogt) +* type checker, inference: @odersky (Martin Odersky), @adriaanm (Adriaan Moors) +* Language specification, value classes: @odersky (Martin Odersky) +* new pattern matcher, implicit search: @adriaanm (Adriaan Moors) +* partest, Continuations Plugin: @phaller (Philipp Haller) +* error handling, lazy vals: @hubertp (Hubert Plociniczak) +* backend: @magarciaEPFL (Miguel Garcia), @gkossakowski (Grzegorz Kossakowski), @dragos (Iulian Dragos) +* repl, compiler performance: @retronym (Jason Zaugg) +* swing: @ingoem (Ingo Maier) +* scaladoc: @dickwall (Dick Wall) +* optimizer: @vladureche (Vlad Ureche), @magarciaEPFL (Miguel Garcia) +* build: @jsuereth (Josh Suereth) +* random compiler bugs: @lrytz, @adriaanm, @hubertp +* documentation: @heathermiller (Heather Miller), @dickwall (Dick Wall) +* cps: @TiarkRompf (Tiark Rompf) -- cgit v1.2.3