[R-pkg-devel] CRAN pending status , left up in the air

[Duncan Murdoch]

On 19/10/2020 1:05 p.m., Spencer Graves wrote:
> 
> 
> On 2020-10-19 10:34, Rafael H. M. Pereira wrote:
>> Thank you  Dirk and Hugo for your responses. I guess I'll just have to be
>> patient and wait.
>>
>> I can only imagine how the CRAN team is overwhelmed by the exponential
>> growth of package submissions. I wonder, though, whether the CRAN
>> maintainers and the R community more broadly are thinking about
>> alternatives to deal with such growing demand without compromising the
>> speed and consistency/quality of package development. Expanding the team of
>> CRAN maintainers would be the most obvious solution but I confess I'm not
>> familiar enough with the whole process to assess what would be the best
>> routes of action to tackle this bottleneck.
> 
> 
> 	  From my experience, it looks to me like their primary approach to
> handling the increased volume has been to improve automation.  In the
> spirit of brainstorming, I'd like to share other ideas on this:
> 
> 
> MAKE IT EASY FOR A USER TO CHECK A DIFF FILE OF "Writing R Extensions"
> COMPARING THE CURRENT VERSION WITH ANY PREVIOUS ONE.

That's already pretty easy on the sources, using svn diff.  The user 
just needs to be comfortable using svn.

For example, assuming you have R-devel checked out, run this to see 
what's changed since Jan 1, 2020:

  svn diff -r {2020-01-01} doc/manual/R-exts.texi

You can do it without checking out a copy with some more typing:

  svn diff -r {2020-01-01} 
--old=https://svn.r-project.org/R/trunk/doc/manual/R-exts.texi

There are probably online web services that do this, but I do have it 
checked out, so I'm not very interested in them.

> 
> 	  For example, every article on Wikipedia has a "View History" tab.
> That lists the dates of all the revisions with a terse summary of what
> was changed in each.  I can click on any two and then click "Compare" to
> see all the changes in that period.
> 
> 
> 	  I'm not going to reread every word of "Writing R Extensions" every
> time I submit something to CRAN.  However, I would be willing to review
> a diff file if it were easy for me to do that.  (And I'm NOT going to
> create my own private file copy of "Writing R Extensions" and manually
> create such a diff file.)

Now you've got it.
> 
> 
> IMPROVE THE COLLABORATION BETWEEN THE CRAN TEAM AND OTHER DOCUMENTATION
> OF HOW TO PREPARE A PACKAGE FOR CRAN
> 
> 
> 	  I know two sources of information on that:
> 
> 
> 		    * Wickham and Bryan, R Packages (https://r-pkgs.org).  I created a
> "cran-comments.md" file based on their recommendations, and missed their
> comment that it should be in ".Rbuildignore".  My latest CRAN submission
> was rejected partly because of that.
> 
> 
> 		    * Colin Fay, "Preparing your package for a CRAN submission"
> (https://github.com/ThinkR-open/prepare-for-cran).  These instructions
> follow Wickham and Bryan in recommending "devtools::revdep_check()".
> Sadly, "revdep_check" is not currently in devtools but in a package
> called revdepcheck.  Worse, that package is not available on CRAN and
> appears twice on GitHub.  The original by bbolker has not been updated
> in 5 years.  The version that is currently maintained is
> "https://github.com/r-lib/revdepcheck".  Fortunately, Hadley Wickham is
> the leading contributor to the latter, so writing him may help correct
> that infelicity, but I should also write to Colin Fay.

Keeping documentation up to date is hard, and maintaining a productive 
collaboration is even harder.  I don't think even writing the suggestion 
in ALL CAPS is enough to bring this about ;-).


> CRAN REVIEW GROUPS:  There are now 41 different "CRAN Task Views".  We
> could ask the maintainer of each Task View to try to recruit a committee
> around each one to discuss coverage and integration.  Each committee
> could be asked to coordinate via email and in virtual meetings.  They
> could be asked to pick 3 standard times for their virtual meetings, so
> anyone in the world would not always be excluded from a meeting that was
> 3 AM their time.  Each package maintainer would be asked to specify at
> least one "Task View" for each package and be willing to discuss
> overlap, etc., with others.  This might be a topic for the next useR
> conference.

I would suggest a more modest goal:  pick one task view in which you 
have an interest, and work to improve it.  Then move on to the next one...

Most of the contributors to R are reasonable people, but they have their 
own priorities.  If you can make it easier for them to achieve their 
priorities, they'll appreciate it.  If you ask them to change their 
priorities, they might not.

Duncan Murdoch