Phase 2

Mid-Phase 2

Saranjeet

• Recently merged PR #70 for PDF download
• Merged favicon (#69)
• Working on comments for #63
• Updated #66 and processing reviews
• Re #71, license is done, working on cover page (some minor technical issues remain), added acknowledgement section
• Re #72, is WIP, will be the last PR to be merged, providing an overview/quick start gude
• Finally, WIP testing chapter (#73), hoping to finish in next weeks
• Buffer period for minor things that come up, e.g. Weblate for translation

Lluís

• Installation from source on Linux is done (#65)
• Source install for windows it's WIP, issue w/ Latex, mostly ok, PR is forthcoming; Thomas has access to Win/Apple Intel and ARM hardware and is happy to check when PR becomes available
• Binary install for windows is also WIP
• Apple hardware is available and writing of install guide has not yet started but will soon

Open questions

• Build vs. install: is installing necessary for going through tests etc? Seems not to be the case for linux, might be different for macOS
• Is make clean necessary or not? unclear... might be good practice (when changing parser code it might be required, but this is an edge case)
• How about Windows? Remove all untracked files? make clean might also be sufficient on windows
• Translations chapter: Michael Chirico is working on it again, Saranjeet will shift focus to Weblate
• Testing PR: https://svn.r-project.org/R/trunk/tests/README What's with the "Historical Information" section? Is this up to date?
  • test-Gct enables stress testing the GC to weed out memory allocation bugs, so this might be useful every now and then
  • other targets do not seem overly useful in general
  • maybe test-Random: check-devel will fail ~1/50 of times due to RNG tests and then only these tests could be rerun to speed things up
• What about adding tests? This can go into regressions tests (when fixing a bug, add report number as comment)
  • reg-tests-1 uses stopifnot(), suffix simply chronologically orders files, most current is reg-tests-1d
  • reg-tests-2 compares against saved output, which can be a bit more finicky as it must work on all supported systems
  • reg-tests-3 checks against output but is allowed to fail
  • When are package level tests used? Probably not relevant for bugfix tests, more a place for tests against new features (for base packages)
  • When adding tests, it has to made sure that they pass on all systems, so some care has to be taken there (e.g. when involving floating point arithmetic), as it's hard to know for sure whether things are ok on Solaris
• What about deadlines? By end of Nov, a case study has to be submitted to Google, so by then all major contributions should be wrapped up