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

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 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. 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. 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.
@ -80,10 +81,11 @@ The TL;DR; of the above very precise workflow version is:
1. Fork Akka
2. Hack and test on your feature (on a branch)
3. Submit a PR
4. Sign the CLA if necessary
4. Keep polishing it until received enough LGTM
5. Profit!
3. Document it
4. Submit a PR
5. Sign the CLA if necessary
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`.