From murdoch.duncan at gmail.com  Sun Dec  5 16:12:03 2010
From: murdoch.duncan at gmail.com (Duncan Murdoch)
Date: Sun, 05 Dec 2010 10:12:03 -0500
Subject: [Rd] Competing with one's own work
In-Reply-To: <loom.20101203T214523-53@post.gmane.org>
References: <4CF91361.7090005@uottawa.ca>
	<4CF91704.7070605@gmail.com>	<003601cb930b$b28205a0$178610e0$@edu>
	<4CF94288.3020301@gmail.com>	<006501cb931f$32a478e0$97ed6aa0$@edu>
	<loom.20101203T214523-53@post.gmane.org>
Message-ID: <4CFBABC3.10702@gmail.com>

On 03/12/2010 4:08 PM, Ben Bolker wrote:
> Ravi Varadhan<rvaradhan<at>  jhmi.edu>  writes:
>
>>
>> "The decision about whether it belongs in a package or in base R is
>> about who should maintain the code."
>>
>> Ok.  I understand it now.
>>
>> Thanks,
>> Ravi.
>>
>
>     A point that may not have been made (sorry if it was and I missed it):
>
> A better question might be how packages get added to the *recommended*
> package list (rather than how code gets added to "base R").

I haven't seen any other response to this, so I'll give an incomplete one.

Packages get added to the recommended list when the core is convinced 
they should be.  It doesn't happen often:  Matrix was the most recent 
addition in R 2.9.0; before that I think it was codetools in 2.5.0.

Being recommended means that the release schedule needs to be 
coordinated with R's releases, because there should be a code freeze 
when R is frozen, and the author needs to be responsive to bug reports. 
  (There can be releases outside of R releases; this is a difference 
from base packages, which are only released with R.)

If a package is recommended, then it needs to be rebuilt to run the R 
tests.  This means tests of base R functionality can depend on a 
recommended package; it also means every additional recommended package 
slows down the tests.  (And it's a real pain on those rare occasions 
when a bug in a recommended package causes a test to fail, because we 
can't necessarily fix the recommended package.)

So just because a package is good quality and contains useful or 
important code, it shouldn't necessarily become a recommended package. 
I don't think there are clear rules about when it should, just as there 
aren't for other R changes.

Duncan Murdoch


> Of the
> 16 recommended packages, 2 are maintained by R-core itself, 12 by various
> R-core members acting as individuals (I assume), and 2 by non-R-core
> people. It seems that if a contributed package sticks around long enough
> and proves itself sufficiently useful and of sufficiently high quality
> (and well enough maintained), that it could then be suggested as
> a recommended package.
>
> i1<- installed.packages()
> i2<- i1[!is.na(i1[,"Priority"]),]
> ff<- function(x) table(sapply(x[,"Package"],maintainer))
> ff(i2[i2[,"Priority"]=="base",])
>
> R Core Team<R-core at r-project.org>
>                                  12
>
> ff(i2[i2[,"Priority"]=="recommended",])
>
>             Brian Ripley<ripley at stats.ox.ac.uk>
>                                                7
> Deepayan Sarkar<deepayan.sarkar at r-project.org>
>                                                2
>   Doug and Martin<Matrix-authors at R-project.org>
>                                                1
>               Luke Tierney<luke at stat.uiowa.edu>
>                                                1
>     Martin Maechler<maechler at stat.math.ethz.ch>
>                                                1
>                    R-core<R-core at R-project.org>
>                                                1
>                    R-core<R-core at r-project.org>
>                                                1
>            Simon Wood<simon.wood at r-project.org>
>                                                1
>         Terry Therneau<therneau.terry at mayo.edu>
>                                                1
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] Competing with one's own work
Duncan Murdoch