contributing.asciidoc 3.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116
  1. [[contributing]]
  2. == Contributing
  3. You are welcome and encouraged to contribute.
  4. This is how.
  5. === Priorities
  6. From the most important to the least important:
  7. * Bugs
  8. * Package issues/additions
  9. * Refactoring
  10. * Features
  11. === Bugs
  12. If you have found a bug, you should open a ticket. Include
  13. everything relevant including the command you used, output,
  14. a link to the code that triggers the issue, why you think
  15. this is a bug, etc.
  16. If you think you have found a bug but you are not sure, you
  17. should open a ticket as previously explained.
  18. If you have found a bug and you need it to be solved RIGHT
  19. NOW, open a ticket as previously explained.
  20. Once you have opened a ticket, be patient, try to answer
  21. questions in a timely manner and confirm that the bug was
  22. indeed fixed when it is.
  23. If you can't be patient, either try to solve the bug and
  24. contribute the fix back or become a paying customer.
  25. === Code
  26. The code is located in the 'core/\*.mk' and 'plugins/\*.mk' files.
  27. The tests are located in the 'test/Makefile' and 'test/*.mk' files.
  28. If you have a fix or a hack for a bug, you should open a
  29. pull request. Any fix should include a test case that fails
  30. before the fix and is working after.
  31. If you have a test case that reproduces a bug, but no fix for
  32. it, you should open a pull request.
  33. Changes need to be tested with at least the `make check`
  34. command. A specific test case can be tested using `make check c=CASE`
  35. with `CASE` the name of the target to run. Output can be
  36. modulated using the `V` variable, which is an integer
  37. from 0 to 4. A typical use would be `make check c=dialyzer V=3`.
  38. The value 4 is particular and shows expanded commands right
  39. before they are executed.
  40. To run tests in parallel, use the `-j` option. It is generally
  41. a good idea to also use the `-k` option to run all tests even
  42. if one fails. For example: `make check -j 32 -k`.
  43. Some changes should be tested against all packages. Continue
  44. reading for more details on testing them.
  45. === Packages
  46. You can search existing packages using the `make search q=STRING`
  47. command. This can be done both from an Erlang.mk project or
  48. directly from the Erlang.mk repository.
  49. Packages can be added to the index using the `pkg_add.sh` script.
  50. [source,bash]
  51. ----
  52. $ git clone https://github.com/$YOURUSERNAME/erlang.mk
  53. $ cd erlang.mk
  54. $ ./pkg_add.sh cowboy git https://github.com/ninenines/cowboy 1.0.0
  55. http://ninenines.eu "Small, fast and modular HTTP server."
  56. $ git push origin master
  57. ----
  58. Before sending a pull request, you should test your package.
  59. You can use the following command: `make check p=PACKAGE`,
  60. where `PACKAGE` is the name of the package, for example
  61. `cowboy`.
  62. To test all packages, the `make packages` command can be used.
  63. This can take a long time. Some packages will fail with certain
  64. versions of Erlang, or if a prerequisite is missing from your system.
  65. You can of course speed things up using the `-j` and `-k` flags.
  66. After all packages have been tested, you can run the command
  67. `make summary` to know what changed since the previous run.
  68. === Documentation
  69. The documentation is always right.
  70. If you think you have found a mistake in the documentation,
  71. this is a bug. You can either open a ticket or send a pull
  72. request.
  73. To make sure that the documentation changes work, install
  74. the listed xref:asciidoc[Requirements] on your system and
  75. run `make docs`.
  76. === Feature requests
  77. If you have an awesome idea or need something that Erlang.mk
  78. doesn't provide yet, open a ticket. Provide as much detail as
  79. possible.
  80. If you have code, great! Open a pull request as previously
  81. explained.
  82. If not, you can still improve your feature request by writing
  83. the related documentation.