[Rd] CRAN policies

[Thomas Lumley]

On Thu, Mar 29, 2012 at 3:30 AM, Gabor Grothendieck
<ggrothendieck at gmail.com> wrote:
> 2012/3/28 Uwe Ligges <ligges at statistik.tu-dortmund.de>:
>>
>>
>> On 27.03.2012 20:33, Jeffrey Ryan wrote:
>>>
>>> Thanks Uwe for the clarification on what goes and what stays.
>>>
>>> Still fuzzy on the notion of "significant" though.  Do you have an example
>>> or two for the list?
>>
>>
>>
>> We have to look at those notes again and again in order to find if something
>> important is noted, hence please always try to avoid all notes unless the
>> effect is really intended!
>>
>>
>> Consider the Note "No visible binding for global variable"
>> We cannot know if your code intends to use such a global variable (which is
>> undesirable in most cases), hence would let is pass if it seems to be
>> sensible.
>>
>> Another Note such as "empty section" or "partial argument match" can quickly
>> be fixed, hence just do it and don't waste our time.
>>
>> Best,
>> Uwe Ligges
>
> What is the point of notes vs warnings if you have to get rid of both
> of them?  Furthermore, if there are notes that you don't have to get
> rid of its not fair that package developers should have to waste their
> time on things that are actually acceptable.  Finally, it makes the
> whole system arbitrary since packages can be rejected based on
> undefined rules.
>

The "notes" are precisely the things for which clear rules can't be
written.  They are reported by CMD check because they are usually
signs of coding errors, but are not warnings because their use is
sometimes justified.

The 'No visible binding for global variable" is a good example.  This
found some bugs in my 'survey' package, which I removed. There is
still one note of this type, which arises when I have to handle two
different versions of the hexbin package with different internal
structures.  The note is a false positive because the use is guarded
by an if(), but  CMD check can't tell this.   So, it's a good idea to
remove all Notes that can be removed without introducing other code
problems, which is nearly all of them, but occasionally there may be a
good reason for code that produces a Note.

But if you want a simple, unambiguous, mechanical rule for *your*
packages, just eliminate all Notes.

   -thomas

-- 
Thomas Lumley
Professor of Biostatistics
University of Auckland