If NOTEs are going to be treated as errors, then a lot of infrastructure (all my packages for optimization and nonlinear modelling, which are dependencies of a few dozen other packages etc.) will disappear. This is because they have version numbering I've been using in some form that pre-dates R and uses YYYY-M(M).D(D). e.g., NOTE "Version contains large components (2018-3.28)"
I believe changing it to a "smaller" value will mean the submission is refused on an ERROR since the numbering will be out of order. So perhaps it is time either to revisit NOTEs to drop some unnecessary ones, and also to make some careful decisions and change critical ones to WARNINGs or ERRORs. One of the major concerns I have is that it is desirable that CRAN be the true repository for R packages, and that increased restrictions -- especially if unnecessary -- will surely increase the movement to informal distribution on other platforms like Github. Such fragmentation of the package universe weakens R as a resource, and we see quite a lot of this recently. I'm strongly in favour of having fairly strict standards, but also of ensuring that only necessary restrictions are enforced. Even more, I believe we must keep working to make satisfying the standards as easy as possible. R has done a good job of this, but there is always room to improve. JN On 2018-04-18 01:40 PM, Hadley Wickham wrote: > For the purposes of CRAN submission, you should basically treat every > NOTE as an ERROR. > > Hadley > > On Wed, Apr 18, 2018 at 3:36 AM, Gertjan van den Burg > <gertjanvandenb...@gmail.com> wrote: >> While waiting to get this message posted to the list, I've solved the >> problem by copying the stdlib rand() and srand() functions into my package >> under a different name. This makes the check pass and ensures my RNG does >> not interfere with R's RNG. >> >> I do think that if this NOTE causes immediate dismissal of a package, it >> shouldn't be a NOTE but an ERROR. Otherwise it just leads to a lot of wasted >> time waiting for a reply from the maintainers to respond to the note. >> >>> Dear all, >>> >>> My CRAN submission doesn't pass the pre-tests and gets archived. I've >>> emailed cran-submissi...@r-project.org explaining that these are false >>> positives, but since I haven't heard back in 10 days I don't think anyone >>> read that. Same thing for the submission comments (which also explained >>> it). >>> >>> The first note is: >>> >>> * checking CRAN incoming feasibility ... NOTE >>> Maintainer: ‘Gertjan van den Burg <gertjanvandenb...@gmail.com>’ >>> >>> New submission >>> >>> Possibly mis-spelled words in DESCRIPTION: >>> GenSVM (8:18, 10:61, 15:2, 16:26, 19:11) >>> Multiclass (4:22) >>> SVMs (14:25, 15:42) >>> misclassifications (11:49) >>> multiclass (8:53, 14:14, 15:31) >>> >>> >>> These words are not mis-spelled, so this is a false positive. >>> >>> The second note is: >>> >>> * checking compiled code ... NOTE >>> File ‘gensvm/libs/gensvm_wrapper.so’: >>> Found ‘rand’, possibly from ‘rand’ (C) >>> Objects: ‘gensvm/src/gensvm_cv_util.o’, ‘gensvm/src/gensvm_init.o’, >>> ‘gensvm/lib/libgensvm.a’ >>> Found ‘srand’, possibly from ‘srand’ (C) >>> Objects: ‘gensvm/src/gensvm_train.o’, ‘gensvm/lib/libgensvm.a’ >>> >>> Compiled code should not call entry points which might terminate R nor >>> write to stdout/stderr instead of to the console, nor use Fortran I/O >>> nor system RNGs. >>> >>> See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual. >>> >>> >>> This is probably why the package is rejected. I have a valid use case for >>> using rand() and srand(): I'm trying to maintain compatibility of this >>> package with the corresponding Python package. By using rand en srand >>> users >>> can reproduce models in both languages. >>> >>> Does anyone have any ideas on how I can get the package excepted to CRAN? >>> >>> Thanks, >>> >>> Gertjan van den Burg >>> >> >> ______________________________________________ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel