[Rd] CRAN policies

[Gabor Grothendieck]

On Wed, Mar 28, 2012 at 11:52 PM, Thomas Lumley <tlumley at uw.edu> wrote:
> 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.

I think it would be more objective and also easiest for everyone if
notes were accepted.

It might be that over time some notes could be split into multiple
cases some of which are warnings and others continue to be notes.

That way package developers don't have to waste their time on getting
rid of notes which don't matter and the CRAN maintainers can turn the
task of reviewing notes over to the computer.

-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com