raboof/pekko
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions 11

Add documentation to contributing workflow (#21703)

Browse source 
* Add documentation to contributing workflow

* fix typo

* Update CONTRIBUTING.md
This commit is contained in:
Mateus Dubiela Oliveira 2016-10-19 14:26:26 -02:00 • committed by Konrad Malawski
parent 9de9642d75
commit c3803d6edf
1 changed files with 6 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

10
CONTRIBUTING.md
View file

@ -65,6 +65,7 @@ The steps are exactly the same for everyone involved in the project (be it core
- Please make sure to follow the general quality guidelines (specified below) when developing your patch. - Please make sure to follow the general quality guidelines (specified below) when developing your patch.
- Please write additional tests covering your feature and adjust existing ones if needed before submitting your Pull Request. The `validatePullRequest` sbt task ([explained below](#validatePullRequest)) may come in handy to verify your changes are correct. - Please write additional tests covering your feature and adjust existing ones if needed before submitting your Pull Request. The `validatePullRequest` sbt task ([explained below](#validatePullRequest)) may come in handy to verify your changes are correct.
1. Once your feature is complete, prepare the commit following our [Creating Commits And Writing Commit Messages](#creating-commits-and-writing-commit-messages). For example, a good commit message would be: `Adding compression support for Manifests #22222` (note the reference to the ticket it aimed to resolve). 1. Once your feature is complete, prepare the commit following our [Creating Commits And Writing Commit Messages](#creating-commits-and-writing-commit-messages). For example, a good commit message would be: `Adding compression support for Manifests #22222` (note the reference to the ticket it aimed to resolve).
1. If it's a new feature, or a change of behaviour, document it on the [akka-docs](https://github.com/akka/akka/tree/master/akka-docs), remember, a undocumented feature is not a feature. If the feature was touching Scala or Java DSL, make sure to document it in both the java and scala documentation (usually in a file of the same name, but under `/scala/` instead of `/java/` etc).
1. Now it's finally time to [submit the Pull Request](https://help.github.com/articles/using-pull-requests)! 1. Now it's finally time to [submit the Pull Request](https://help.github.com/articles/using-pull-requests)!
1. If you have not already done so, you will be asked by our CLA bot to [sign the Lightbend CLA](http://www.lightbend.com/contribute/cla) online CLA stands for Contributor License Agreement and is a way of protecting intellectual property disputes from harming the project. 1. If you have not already done so, you will be asked by our CLA bot to [sign the Lightbend CLA](http://www.lightbend.com/contribute/cla) online CLA stands for Contributor License Agreement and is a way of protecting intellectual property disputes from harming the project.
1. If you're not already on the contributors white-list, the @akka-ci bot will ask `Can one of the repo owners verify this patch?`, to which a core member will reply by commenting `OK TO TEST`. This is just a sanity check to prevent malicious code from being run on the Jenkins cluster. 1. If you're not already on the contributors white-list, the @akka-ci bot will ask `Can one of the repo owners verify this patch?`, to which a core member will reply by commenting `OK TO TEST`. This is just a sanity check to prevent malicious code from being run on the Jenkins cluster.
@ -80,10 +81,11 @@ The TL;DR; of the above very precise workflow version is:
1. Fork Akka 1. Fork Akka
2. Hack and test on your feature (on a branch) 2. Hack and test on your feature (on a branch)
3. Submit a PR 3. Document it
4. Sign the CLA if necessary 4. Submit a PR
4. Keep polishing it until received enough LGTM 5. Sign the CLA if necessary
5. Profit! 6. Keep polishing it until received enough LGTM
7. Profit!
Note that the Akka sbt project is large, so `sbt` needs to be run with lots of heap (1-2 Gb). This can be specified using a command line argument `sbt -mem 2048` or in the environment variable `SBT_OPTS` but then as a regular JVM memory flag, for example `SBT_OPTS=-Xmx2G`, on some platforms you can also edit the global defaults for sbt in `/usr/local/etc/sbtopts`. Note that the Akka sbt project is large, so `sbt` needs to be run with lots of heap (1-2 Gb). This can be specified using a command line argument `sbt -mem 2048` or in the environment variable `SBT_OPTS` but then as a regular JVM memory flag, for example `SBT_OPTS=-Xmx2G`, on some platforms you can also edit the global defaults for sbt in `/usr/local/etc/sbtopts`.