Skip to content

Contributing

Lionel Henry edited this page Oct 31, 2018 · 2 revisions

Conventions

  • Use 8-width tabs. A level 4 indent is 4 spaces, level 8 is 1 tab, level 12 is 1 tab + 4 spaces, etc.

  • Use /* */ comments in C code, even for single-line comments. Use double ## in R code.

  • Use nprot to count the number of protected variables.

Writing tests

  • tests/reg-tests-1d.R is the current general purpose test file, for R >= 3.4.0.

  • Use one solid paragraph (no newlines) per test. The paragraph should start and end with comments.

  • If you change the session's state in your test (set options, create variables), restore the original state at the end.

  • Some test files save the console output to a .Rout file that is compared to a .Rout.save. If you add a test or somehow change the output, update the .Rout.save file and commit it.

Running tests

See tests/README.

  • Note that for complete testing you will need a number of other packages installed and available, so if you have a CRAN installation, set R_LIBS (perhaps in ~/.R/check.Renviron) to include it before running these tests. For example, some of the tests on 'nlme' depend on 'Hmisc', and there are a number of cross references from help pages to CRAN packages.

  • Set the TEST_MC_CORES environment variables to run tests in parallel.

Creating patches

The simplest way is to create them from git commits or git branches. Send a pull request or branch to your github's mirror repo and append .patch to a PR or commit URL. In case of a branch, all commits are folded in a single patch.

To do this manually, use git format-patch. When given one argument (a revision), it creates patches for each commit from that revision to the current head:

git checkout mypatch
git format-patch trunk

Squash the commits together beforehand if you'd like to create a single patch.

Submitting

If the patch is trivial (fixes a bug, implements a small feature that was already discussed), create a bugzilla report with a reprex if there isn't one already. Attach the patch, click on "Show Advanced Fields" to reveal the "Content Type" checkbox and declare the attachment is a patch. This way the patch is properly formatted in the bug report.

If the patch introduces a new feature or change the API, it's probably better to discuss it first on r-devel or with the relevant R core maintainer.

Clone this wiki locally