r-hub
Reverse dependencies check
I think this needs a little more fleshing out - typically you want to run it twice. The first time you run ~2-4 weeks before CRAN submission, giving revdep maintainers time to fix any issues. Ideally this would allow you to automatically inform all revdep maintainers of problems. The second time you run it just prior to CRAN submission, giving CRAN an update about what packages have problems, and giving maintainers a final warning.
Good point.
The idea is that you can run it any time you want, at least initially. We probably don't want to allow it for the CI, though, because it can be quite expensive for many revdeps.
It could compare results to the current CRAN results. Or, if it turns out that we can afford some more cpu cycles, then we can just run it twice, in parallel, once for the package under testing, once for the current release (or the specified version, to be worked out).
I think the other important thing is being able to choose to send the results to downstream maintainers. This is a big hassle for me - testthat now has >700 dependencies, so just reading through the results and sending problems on to individual maintainers is a lot of work.
Yes, I know about this, I usually get your automated emails. :) I know devtools has tools for this, and there is some stuff in base R packages as well, to compare the output of checks, etc. So, yes, I agree that power-maintainers need this.
With r-hub we'll be able to refer to the full build log, and the exact machine config, and on Linux (which will be used for the revdep checks) and a Dockerfile, so people will be able to investigate.