Chapter 31. Contributing

You are welcome and encouraged to contribute.

This is how.

31.1. Priorities

From the most important to the least important:

  • Bugs
  • Package issues/additions
  • Refactoring
  • Features

31.2. Bugs

If you have found a bug, you should open a ticket. Include everything relevant including the command you used, output, a link to the code that triggers the issue, why you think this is a bug, etc.

If you think you have found a bug but you are not sure, you should open a ticket as previously explained.

If you have found a bug and you need it to be solved RIGHT NOW, open a ticket as previously explained.

Once you have opened a ticket, be patient, try to answer questions in a timely manner and confirm that the bug was indeed fixed when it is.

If you can’t be patient, either try to solve the bug and contribute the fix back or become a paying customer.

31.3. Code

The code is located in the core/*.mk and plugins/*.mk files. The tests are located in the test/Makefile and test/*.mk files.

If you have a fix or a hack for a bug, you should open a pull request. Any fix should include a test case that fails before the fix and is working after.

If you have a test case that reproduces a bug, but no fix for it, you should open a pull request.

Changes need to be tested with at least the make check command. A specific test case can be tested using make check c=CASE with CASE the name of the target to run. Output can be modulated using the V variable, which is an integer from 0 to 4. A typical use would be make check c=dialyzer V=3. The value 4 is particular and shows expanded commands right before they are executed.

To run tests in parallel, use the -j option. It is generally a good idea to also use the -k option to run all tests even if one fails. For example: make check -j 32 -k.

Some changes should be tested against all packages. Continue reading for more details on testing them.

31.4. Packages

You can search existing packages using the make search q=STRING command. This can be done both from an Erlang.mk project or directly from the Erlang.mk repository.

Packages can be added to the index using the pkg_add.sh script.

$ git clone https://github.com/$YOURUSERNAME/erlang.mk
$ cd erlang.mk
$ ./pkg_add.sh cowboy git https://github.com/ninenines/cowboy 1.0.0
  http://ninenines.eu "Small, fast and modular HTTP server."
$ git push origin master

Before sending a pull request, you should test your package. You can use the following command: make check p=PACKAGE, where PACKAGE is the name of the package, for example cowboy.

To test all packages, the make packages command can be used. This can take a long time. Some packages will fail with certain versions of Erlang, or if a prerequisite is missing from your system. You can of course speed things up using the -j and -k flags.

After all packages have been tested, you can run the command make summary to know what changed since the previous run.

31.5. Documentation

The documentation is always right.

If you think you have found a mistake in the documentation, this is a bug. You can either open a ticket or send a pull request.

To make sure that the documentation changes work, install the listed Requirements on your system and run make docs.

31.6. Feature requests

If you have an awesome idea or need something that Erlang.mk doesn’t provide yet, open a ticket. Provide as much detail as possible.

If you have code, great! Open a pull request as previously explained.

If not, you can still improve your feature request by writing the related documentation.