[R-pkg-devel] CRAN pretest archived because of 2 NOTEs

[Ben Bolker]

  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
>> <gertjanvandenburg at 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-submissions at 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 <gertjanvandenburg at 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 at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>>
>>
> 
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>