Feedback, discussions, and ideas around CRANhaven

[HenrikBengtsson]

The initial objective is for CRANhaven to serve as a discussion point. Things to discuss are:

• How long should packages stay on CRANhaven before being dropped (currently ~4~ 5 weeks)?

• What should happen to packages that expire on CRANhaven? Should we have a CRANafterlife too, where package are moved indefinitely?

  • https://cran.r-universe.dev/ is effectively what a CRANafterlife would be

• How to handle CRAN packages moved to Bioconductor? Should be rare.

• Should we treat packages that are archived on request of the maintainer differently from those archived by the CRAN Team?

• Can this be used by Bioconductor as a cushion for packages coming-and-going on CRAN? For instance, maybe BiocManager::install() could append https://cranhaven.r-universe.dev to the repos option? Only for Bioc release - and let the pain be felt for Bioc devel? What about Bioc build systems?

• Is this something CRAN could/should host? The benefit for them would be fewer revdep packages being dropped and therefore fewer resubmissions, because the culprit archived package is likely to return soon anyway.

• Extend time limit when CRAN incoming is down for maintenance.

• Annotation: Monitor CRAN incoming for returning packages and annotate accordingly in dashboard, e.g. cransays (https://r-hub.github.io/cransays/articles/dashboard.html) and ciw (https://dirk.eddelbuettel.com/blog/2024/03/13/#ciw_0.0.1)

• Annotation: Report on activity on packages' GitHub and GitLab commit logs, e.g. as sparklines

• Annotation: Reason for being archived. Already in the "comment" column today, but we could do more parsing and reporting on, say, "archive by maintainer", "archived because of dependency being archived", ..

• Annotation: Report on build issues vs check issues.

  • Build issues: Fail to build, Builds, but only with --no-build-vignettes
  • Check issues: Level NOTE, WARNING, ERROR
  • Excerpt of the most important issue
  • Deep link to the build/check results
  • See also https://github.com/r-hub/cchecksbadges

[llrs]

AFAIK, Bioconductor would be grateful for a solution that allowed them to keep some packages. There is no mechanism to alert repository maintainers/volunteers, so the Bioconductor core team discover CRAN packages archived on the go, which leads to unpleasant surprises.

For packages moved between recognized repositories, ideally this would be handled by the package manager, or by install.packages. As there are no agreement between repositories on how to signal that packages come from a repository this could be dealt with the addition of an onLoad warning (not sure how easy would that be). So keeping in them here, for a while (same default time as other packages archived).

As someone with a package that I hope will be archived soon (and seeing other similar packages archived on github but not on CRAN) I think they should be dealt the same as other packages. If someone is interested in maintaining them they can step up and continue working from what was done.

[wlandau]

I wonder if there is a way R-releases can support CRANhaven somehow. Maybe CRANhaven could leverage https://r-releases.r-universe.dev as a backup repo?

[wlandau]

@shikokuchuo pointed out that packages remain on the GitHub CRAN mirror even after CRAN archives them. ravetools is an example, c.f. https://cran.r-project.org/web/packages/ravetools/index.html and https://github.com/cran/ravetools. And on my end, install.packages("ravetools", repos = "https://cran.r-universe.dev") successfully installs the latest CRAN release.

@HenrikBengtsson, are https://cran.r-universe.dev and https://github.com/cran already enough of a CRAN haven?

[HenrikBengtsson]

@HenrikBengtsson, are https://cran.r-universe.dev and https://github.com/cran already enough of a CRAN haven?

It's already building based on https://github.com/cran, cf. https://www.cranhaven.org/#under-the-hood.

One of the objectives for CRANhaven is to serve only "recently" archived CRAN packages and give a temporary cushion bridging the extra time package maintainers needs to get their package back on CRAN.

I think there needs to be a balance between low friction and feeling the pain to put the pressure on getting things fixed. Right now, some of that pressure happens when all revdep maintainers get notified that some package they depend on will go away. The rest of the world does not know until the package(s) fall of CRAN. CRANhaven means to smooth out those rough rides and effectively extend the time when end-users are affected by archived packages. Also, one idea is for BiocManager::install() to use CRANhaven as a fallback for packages that have temporarily fallen off CRAN. We're experimenting with what the actual time limit (current 5 weeks) should be, and we might increase it to cover more packages.

In the best of the worlds, the CRAN Team will find CRANhaven useful for "offboarding" packages and host their own version of it. For instance, right now they're paying the price of having to review resubmissions from all revdep packages that fell off when a package was archived. [UPDATE 2024-03-27: This might actually not be how it works - I'm monitoring CRANhaven; it looks like revdep packages that were archived due to another package being archived, do indeed automatically return in the reverse process.] That seems like waste of time and resources. They might even speed up the archiving process. Instead of two weeks, developers gets put in the "offboarding" repo immediately, and the process is as before, with the advantage that the rest of the world also knows the package in about to become archived. (Just thinking out loud here)

For packages archived long-term, then, yes, https://cran.r-universe.dev can serve as the (currently imaginary) CRANafterlife repo, where packages end up when they fall off CRANhaven.