[Rd] Minimum requirements for package submission

Dirk Eddelbuettel edd at debian.org
Wed Aug 28 17:47:52 CEST 2013


On 28 August 2013 at 11:18, Duncan Murdoch wrote:
| On 28/08/2013 10:59 AM, Dirk Eddelbuettel wrote:
| > On 28 August 2013 at 09:44, Hadley Wickham wrote:
| > | >> Related rant: I really wish we had "CHANGES" file, or a section in the
| > | >> manuals. It is virtually impossible to look at a current "Writing R
| > | >> Extensions" manual, and a previous one, in order to get a succinct view of
| > | >> what changed.  Having to diff the NEWS files, or glancing at commit logs
| > | >> via
| > | >> the RCS is a very poor proxy.
| > | >
| > | > I don't understand the difference between the CHANGES file you are asking
| > | > for and the NEWS file.  Do you want something in purely chronological order,
| > | > rather than categorized as NEWS is?
| > |
| > | I think Dirk was talking about a CHANGES/NEWS file for "Writing R extensions"
| >
| > Yup. In the sense of "something to look at to see what one may need to change".
| >
| > Eg for Debian, the "Policy" document has a version number making discussion /
| > comparison and reference more tangible.  Also, if/when an update is made, an
| > 'upgrade checklist' is provided -- see eg [1] for the most recent annoucement
| > [2] for the policy manual web presence, and [3] for the complete checklist
| > with a roll-back history.
| >
| > I am not suggesting this exact format. I am merely pointing that it
| > (currently) takes a couple of extra steps to stay on top of required changes,
| > which in turn leads to everybody just uploading to CRAN as a trial, which in
| > turn overburdens the CRAN maintainers.  Seems suboptimal to me.
| 
| There is the "--as-cran" option to R CMD check, so it's not quite as bad 

Sure. I use that all the time, and it is the sole reason I keep an r-devel
build around. 

But it is _reactive_. I suggest something proactive.

| as you suggest, but as others have mentioned there is some ambiguity 
| about how NOTEs in those checks are treated.  But isn't any "overburden" 
| mainly a CRAN problem, so not something to be discussed on this list?
| 
| To be clear:  I am not a CRAN member.  I only know CRAN policy as an 
| outsider, same as you.  And before an argument starts about where CRAN 
| policy discussions should take place:  this is certainly not the 

This is the R development list. I have been subscribed for fourteen years,
and to the best of my recollection there never was any discussion of
this. Here.  At the place created to discuss R development issues. Ie work
meant for CRAN. 

In my book, that's a bug and not a feature.

| place.   You can ask CRAN where such discussions should happen, but I 
| suspect the answer will be "nowhere public", because most public 
| discussions of CRAN policy devolve very quickly into ridiculous demands 
| on the volunteers who run it.

By never engaging in the discussions the CRAN maintainers do not exactly help
their case, or for that matter their users (eg those submitting packages).

Dirk

ObDisclaimer: I remain a really huge fanboy of CRAN, and almost always defend
it in dicussions with other R users (not all of which are all that kindly
disposed to CRAN these days).  But even I am at a loss for explanations for
some of these things, and am tired of the current back-and-forth on submissions.
The fact that _overnight changes_ to r-devel are reasons for reject are just
silly. 

ObDisclaimer 2: I am not complaining to you. You just happent to be just
about the only R Core member engaging here.  I am grateful that you do, and I
do understand that your ability to affect change is also limited. I merely
assume it is larger than mine.


-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com



More information about the R-devel mailing list