Re: [R-pkg-devel] CRAN pending status , left up in the air
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
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN pending status , left up in the air
My 'revdepcheck' is obsolete, superseded by r-lib/revdepcheck (which it does predate by about a year ...) Dirk Eddelbuettel maintains an automated system for diffs of the CRAN repository policy https://github.com/eddelbuettel/crp , or follow @CRANPolicyWatch -- similar to your idea about WRE diffs. You can view a history of WRE (with diffs) at https://github.com/wch/r-source/commits/trunk/doc/manual/R-exts.texi I believe CRAN has devoted some resources to hiring editorial assistants who handle some of the lower-level tasks ... On 10/19/20 1:05 PM, 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. 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.) 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. 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. Comments? Best Wishes, Spencer Graves best Rafael H M Pereira On Mon, Oct 19, 2020 at 5:46 AM Hugo Gruson wrote: Hi all, this is a bit tricky since the documentation on the dashboard comes from an official, authoritative, source: the R journal [1]. "pending: if a decision is pending a response from the package maintainer: If an additional issue was present in the package that we cannot check for in the incoming checks (such as the BLAS issues mentioned in the section above), the maintainer is automatically asked whether these issues have been fixed. Same is true for change of maintainer (or maintainer's mail address) where the old maintainer (old address) is automatically asked to confirm the maintainer change. The answers have to be processed manually." As Dirk explains and as reported in https://github.com/lockedata/cransays/issues/29, it is likely not true anymore but in the absence of further official information, it is difficult to issue a fix. A later issue
Re: [R-pkg-devel] CRAN pending status , left up in the air
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. 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.) 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. 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. Comments? Best Wishes, Spencer Graves best Rafael H M Pereira On Mon, Oct 19, 2020 at 5:46 AM Hugo Gruson wrote: Hi all, this is a bit tricky since the documentation on the dashboard comes from an official, authoritative, source: the R journal [1]. "pending: if a decision is pending a response from the package maintainer: If an additional issue was present in the package that we cannot check for in the incoming checks (such as the BLAS issues mentioned in the section above), the maintainer is automatically asked whether these issues have been fixed. Same is true for change of maintainer (or maintainer's mail address) where the old maintainer (old address) is automatically asked to confirm the maintainer change. The answers have to be processed manually." As Dirk explains and as reported in https://github.com/lockedata/cransays/issues/29, it is likely not true anymore but in the absence of further official information, it is difficult to issue a fix. A later issue of the R journal [2] introduces the "waiting" and "newbies" categories but does not expand on the new role of "pending". Best, Hugo [1]: https://journal.r-project.org/archive/2018-1/cran.pdf [2]: https://journal.r-project.org/archive/2019-1/cran.pdf On 19/10/2020 02:18, Dirk Eddelbuettel wrote: On 18 October 2020 at 20:56, Rafael H. M. Pereira wrote: | The CRAN incoming Dashboard indicates that the status of my package (r5r) | is "pending", which means 'the CRAN maintainers are waiting for an action | on your side. You should check your emails!'. AFAICT the text there is wrong: it corresponds to s
Re: [R-pkg-devel] CRAN pending status , left up in the air
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. best Rafael H M Pereira On Mon, Oct 19, 2020 at 5:46 AM Hugo Gruson wrote: > Hi all, > > this is a bit tricky since the documentation on the dashboard comes from > an official, authoritative, source: the R journal [1]. > > "pending: if a decision is pending a response from the package > maintainer: If an additional issue was present in the package that we > cannot check for in the incoming checks (such as the BLAS issues > mentioned in the section above), the maintainer is automatically asked > whether these issues have been fixed. Same is true for change of > maintainer (or maintainer's mail address) where the old maintainer (old > address) is automatically asked to confirm the maintainer change. The > answers have to be processed manually." > > As Dirk explains and as reported in > https://github.com/lockedata/cransays/issues/29, it is likely not true > anymore but in the absence of further official information, it is > difficult to issue a fix. > > A later issue of the R journal [2] introduces the "waiting" and > "newbies" categories but does not expand on the new role of "pending". > > Best, > > Hugo > > [1]: https://journal.r-project.org/archive/2018-1/cran.pdf > [2]: https://journal.r-project.org/archive/2019-1/cran.pdf > > On 19/10/2020 02:18, Dirk Eddelbuettel wrote: > > > > On 18 October 2020 at 20:56, Rafael H. M. Pereira wrote: > > | The CRAN incoming Dashboard indicates that the status of my package > (r5r) > > | is "pending", which means 'the CRAN maintainers are waiting for an > action > > | on your side. You should check your emails!'. > > > > AFAICT the text there is wrong: it corresponds to state 'waiting' as > > 'pending' means CRAN is pondering the state of the package. > > > > Your package has only been there for three (mostly weekend) days which is > > nothing. I have one 'waiting' for five days now and it is simply > (AFAICT) a > > false positive. Plus, it had already been delayed by a spurious > compilation > > error on their end before that so the total is well over a week now. Very > > frustrating. But there is exactly zero you or I can do about it. > > > > | However, I haven't received any email with guidance on how to proceed. > Is > > | there any CRAN webpage to check the latest check results and get a > sense of > > | what I should be doing? > > > > No. > > > > I can only suggest to trust official documentation (Writing R Extensions, > > CRAN Repository Policy) more. Asking here is also better than guessing. > > > > Dirk > > > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN pending status , left up in the air
Hi all, this is a bit tricky since the documentation on the dashboard comes from an official, authoritative, source: the R journal [1]. "pending: if a decision is pending a response from the package maintainer: If an additional issue was present in the package that we cannot check for in the incoming checks (such as the BLAS issues mentioned in the section above), the maintainer is automatically asked whether these issues have been fixed. Same is true for change of maintainer (or maintainer's mail address) where the old maintainer (old address) is automatically asked to confirm the maintainer change. The answers have to be processed manually." As Dirk explains and as reported in https://github.com/lockedata/cransays/issues/29, it is likely not true anymore but in the absence of further official information, it is difficult to issue a fix. A later issue of the R journal [2] introduces the "waiting" and "newbies" categories but does not expand on the new role of "pending". Best, Hugo [1]: https://journal.r-project.org/archive/2018-1/cran.pdf [2]: https://journal.r-project.org/archive/2019-1/cran.pdf On 19/10/2020 02:18, Dirk Eddelbuettel wrote: On 18 October 2020 at 20:56, Rafael H. M. Pereira wrote: | The CRAN incoming Dashboard indicates that the status of my package (r5r) | is "pending", which means 'the CRAN maintainers are waiting for an action | on your side. You should check your emails!'. AFAICT the text there is wrong: it corresponds to state 'waiting' as 'pending' means CRAN is pondering the state of the package. Your package has only been there for three (mostly weekend) days which is nothing. I have one 'waiting' for five days now and it is simply (AFAICT) a false positive. Plus, it had already been delayed by a spurious compilation error on their end before that so the total is well over a week now. Very frustrating. But there is exactly zero you or I can do about it. | However, I haven't received any email with guidance on how to proceed. Is | there any CRAN webpage to check the latest check results and get a sense of | what I should be doing? No. I can only suggest to trust official documentation (Writing R Extensions, CRAN Repository Policy) more. Asking here is also better than guessing. Dirk __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] (no subject)
Hello, Usually such problems with pkgdown will come from your pkgdown configuration. I see (thanks to a search engine :-) and sorry if my search result is wrong ) that you actually write to exclude all articles * your configuration https://github.com/maRce10/warbleR/blob/7c313bd4388c908df9055a952badca8605b75468/pkgdown/_pkgdown.yml#L4 (btw you also have a file called pkgdown.yml there, that is probably useless?) * documentation of how to configure the articles index https://pkgdown.r-lib.org/reference/build_articles.html#index-and-navbar So you'll need to either remove the "articles" field from your configuration (to use the default ordering etc.) or add more information to it, following the docs. As to why this did not happen before, I'd assume it is the articles index was added fairly recently https://www.tidyverse.org/blog/2020/03/pkgdown-1-5-0/#articles Best wishes Maëlle. PS: For questions directly related to pkgdown I'd tend to rather post on https://community.rstudio.com/c/package-development/11 Den måndag 19 oktober 2020 02:06:38 CEST, Marcelo Araya Salas skrev: Hi all Hi all, I got this warning message when I run pkgdown::build_site() Warning: Vignettes missing from index: (all the vignette names here) And then the vignettes are not included in the package website This didn't happen before. Does anyone know how to avoid this? Thanks! Marcelo [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
