From b5d4cb91f80c833795a2d87050c3674bb7aecdc5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Tue, 3 Oct 2017 13:39:41 +0200 Subject: Update Hugo, docs --- docs/en/erlang.mk/1/guide/contributing/index.html | 255 +++++++++++----------- 1 file changed, 129 insertions(+), 126 deletions(-) (limited to 'docs/en/erlang.mk/1/guide/contributing/index.html') diff --git a/docs/en/erlang.mk/1/guide/contributing/index.html b/docs/en/erlang.mk/1/guide/contributing/index.html index 0d549029..c6719e0c 100644 --- a/docs/en/erlang.mk/1/guide/contributing/index.html +++ b/docs/en/erlang.mk/1/guide/contributing/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Contributing @@ -67,137 +67,140 @@

Contributing

-

You are welcome and encouraged to contribute.

-

This is how.

-
-

Priorities

-
-

From the most important to the least important:

-
    -
  • -

    -Bugs -

    -
    • -
  • -

    -Package issues/additions -

    -
    • -
  • -

    -Refactoring -

    -
    • -
  • -

    -Features -

    -
    • -
-
-
-
-

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.

-
-
-
-

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.

-
-
-
-

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.

-
-
-
-

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.

-
-
-
-

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.

-
-
+

You are welcome and encouraged to contribute.

+

This is how.

+
+

Priorities

+
+

From the most important to the least important:

+
    +
  • +

    +Bugs +

    +
    • +
  • +

    +Package issues/additions +

    +
    • +
  • +

    +Refactoring +

    +
    • +
  • +

    +Features +

    +
    • +
+
+
+
+

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.

+
+
+
+

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.

+
+
+
+

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.

+
+
+
+

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.

+
+
+
+

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.

+
+
+ + +