-
Notifications
You must be signed in to change notification settings - Fork 1
/
TODO.txt
44 lines (30 loc) · 3.56 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
check inputs for Insol (latitude within -pi/2 - pi/2)
check caloric insolation calculation -> done
change references to ftp sites and put warning that these sources are unstable -> done
check documentation annual mean insolation and its plotting function
double check Milankovitch works with polar night
add polar_night option in the Milankovitch plot documentation
takahito : give longitude of perihelion
takahito : fix 50yr lag in Laskar -> done
takahito : explain doc long perihelion wrt to vernal equinox
fix obliquity function
Please always read the CRAN policies first. This document gives some additional hints for a useful CRAN submission, especially for new submissions.
Unless there are good reasons, packages submitted to CRAN are expected to pass R CMD check --as-cran, and you will be asked to fix and resubmit your package if it gives warnings or significant notes. To avoid this, you should run R CMD check --as-cran yourself with a current development version of R before submitting to CRAN.
You can use the following web services to supplement your own tests:
Winbuilder checks packages on Windows using a current development version of R. The same infrastructure is used by the CRAN team for checking submitted packages.
R-hub can be used to check packages on multiple platforms and versions of R using virtual machines. The service is not maintained by CRAN and hence different check settings may be in place.
In addition to the automated checks, we expect package authors to follow good practices that make their package more accessible and useful to the wider R community.
The most important way to do this is to write an informative entry in the Description field in the DESCRIPTION file (see the relevant section of the Writing R Extensions manual). The Title and Description fields are shown at the top of the CRAN landing page for the package, and should therefore be written with care.
Make the Description as informative as possible for potential new users of your package. If in doubt, make the Description longer rather than shorter, but try to avoid redundancies such as repetitions of the package name.
Write function names including parentheses as in foo() but without quotes.
Put non-English usage, including names of other packages and external software, in single quotes. Example: 'OpenSSL'.
Relevant citations should be included in the description. These should be in author-year style, preferably followed by an identifier such as DOI, arXiv id, or ISBN for published materials.
DOIs should be enclosed in angle brackets, and formatted as <doi:10.prefix/suffix>. Example: Sugihara (1994) <doi:10.1098/rsta.1994.0106>.
arXiv identifiers should be enclosed in angle brackets, and formatted as <arXiv:YYMM.NNNNN>. Example: Srivastava et al. (2011) <arXiv:1103.3817>.
Similarly, relevant URLs should be included in the description, also enclosed in angle brackets (see the Writing R Extensions manual for details). Example: <https://cran.r-project.org/>.
Preferably, provide an Authors@R field in DESCRIPTION giving all the authors, including contributors and copyright holders, with appropriate roles. For persons with an ORCID identifier (see https://orcid.org/ for more information, provide the identifier via an element named "ORCID" in the comment argument of person(). Example: person("Achim", "Zeileis", comment = c(ORCID = "0000-0003-0918-3766")).
add Michel's orcid: Michel Crucifix (0000-0002-3437-4911)
test La04 50a shift
test reproduction of Ber90
verify Ber90 uses the right constants
verify compatibility with insolation values provided by https://doi.pangaea.de/10.1594/PANGAEA.56040