Your points are well taken, but it's also necessary (IMO) for the CRAN maintainers to have some flexibility, while still being able to hold package maintainers to account.
Long-time package maintainers (like you) have some issues that new submitters don't; the large-component check was "only" instituted three years ago <https://github.com/wch/r-source/commit/1923067f0d8fd691158548f58ba2e9a19e4b52f5>. As Duncan suggested, CRAN maintainers are more likely to make allowances for long-time maintainers ... In the spirit of your suggestion, I would say I'd like to see the information provided by Dirk at <http://dirk.eddelbuettel.com/blog/2017/08/10/> about providing defaults/exceptions for the spell-checker made public/official -- several recent posts have shown package maintainers getting distracted by spell-check false positives and missing potentially more serious NOTEs. (This information may exist elsewhere, but I couldn't find it either in "Writing R Extensions" or the CRAN Repository Policy ...) On 2018-04-18 02:13 PM, J C Nash wrote: > 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 > ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel