Post

Quick poll: When would you like CRAN to archive your package? A: Umm, never? B: Three days before posit::conf, where you're giving a talk about said package

More or less. I can come up with more positive ways to spin it. The compounding issue here is that contacting CRAN for an exception can be hard.

The embarassing thing is that packages with a minimal test suite probably have an easier time (I suppose the ASAN issue was flagged by the package's test suite?).

0 reposts0 likes

Yep. CRANs policies have caused a lot of package maintainers to: 1. Remove tests 2. Remove runnable examples 3. Remove URLs in docs and references (CRAN checks URLS) It's not purely a negative thing though, it's complicated.

Complicated indeed! Consider URL checks: it is mucg better to ensure that documentation is reachable. Yet sometimes even an archive.org redirect times out. Or a primary site times out (as they defend against DDOS and 'count hits / ip'). All this imposes 'work' on us, but raises overall quality.

And ASAN checks, painful as they are, most often reveal genuine bugs. So checking those is good too. We have the same issues as Debian maintainers (when, say, obscure hardware breaks) and yes a common way out can be to ... disable a test conditionally. Been there, done that. Also at CRAN.

I agree that running a test suite with ASAN can be very useful. I'm just surprised of the automated action to remove / archive a package when a test failure is detected (I'm not aware of Debian having a similar policy btw 😀). But I suspect this is not a new controversy in the R ecosystem.