(Staging) Status notice?

[eitsupi]

Disclaimer: I am one of maintainers of the polars package.

I noticed the polars package was in errors when I checked the staging repository.
r-multiverse/status@aa44559#diff-3f26ae98ac184c08e431340b627661a68efa10c665f8b119ef83135258561183

As I understand it, two reasons for the error exist:

1. A file on the Internet referenced from within the vignette has been removed (Perhaps occurring in early January? Fixed by ci: ensure install R on ubuntu runner, and other minor fixes to make ci passed pola-rs/r-polars#1316 (comment)).
2. A new version of the patrick package that we rely on for testing has been released in CRAN (2025-01-27).

These failures did not exist as of the most recent release of the polars package, so I was unaware of the problem on R-multiverse.

If these problems are left unaddressed, polars will disappear from the production repository, right?

It would be good to be notified in advance.
It may be desirable to operate in such a way that the moderators are notified and the moderators contact the maintainers.

[eitsupi]

I think this is a pretty edge case, but if errors occurs simultaneously due to two reasons, a breaking change in a dependent package on CRAN and other factor, as in this case, it may not be possible to fix the error on the Staging repository due to the date constraints of the P3M snapshot (#129).
Of course could be solved if an extra release could be created for that purpose...

In my case, patrick 0.2.0 is used on the Staging repository because the release of patrick 0.3.0 was on 2025-01-27, a little after the snapshot date of 2025-01-15.
However, a patch was needed to address patrick 0.3.0 in order to resolve the error in the Community repository.
(Fortunately, this change was compatible with patrick 0.2.0 and passed the test on the Staging repository.)

[eitsupi]

I think r-universe-org/help#559 is useful.

[wlandau]

It would be good to be notified in advance. It may be desirable to operate in such a way that the moderators are notified and the moderators contact the maintainers.

https://r-multiverse.org/status/ continuously posts RSS feeds with the status of each package (example: https://r-multiverse.org/status/staging/polars.xml). Mainly, this is for people who maintain and follow specific packages. Do you think it would be reasonable for moderators to subscribe to the feeds of packages in their subject matter areas?

I think r-universe-org/help#559 is useful.

I agree. We just released multiverse.internals 0.3.6 to freeze CRAN (via p3m) at the start of the staging period. It's unfortunate that this may create conflict between the Community tests and the Staging ones, but hopefully surprises in Staging will happen less often from updates on CRAN.

[eitsupi]

Thanks for your reply!
As for RSS, I think it's a great and good mechanism to meet some needs.

But I think that the disappearance of packages from the production repository can have a pretty big impact, and I think that monitoring the difference between the production repository and the next production repository candidate should be done in a special dashboard (assuming something like CRANhaven).

[wlandau]

https://github.com/r-multiverse/staging/blob/main/snapshot.json the list of packages and remote SHAs of packages in Staging, and I added commits to include this manifest in Production snapshots as well. I think this may help downstream tools track changes and removals.

[wlandau]

We are updating Staging and the infrastructure for Production, c.f. #135. This is causing a temporary issues with Staging versions. For example, https://r-multiverse.org/status/staging/rlang.html:

R-multiverse found issues with package rlang version 1.1.4 remote hash ae699d14ce32444ecd797e287f9384faf3726c74 (as of 2025-02-28).

On CRAN, this package had version 1.1.5 during the first day of the most recent R-multiverse Staging period. The version on R-multiverse is lower, which causes install.packages() to prefer CRAN. If you have not already done so, please ensure the latest GitHub/GitLab release has a suitably recent version in the DESCRIPTION file.

rlang is supposed to be at version 1.1.5 in Staging.

https://staging.r-multiverse.org/builds

[wlandau]

In the case of rlang, mirai, and nanonext, rerunning https://github.com/r-multiverse/staging/blob/main/.github/workflows/update.yaml and then https://github.com/r-multiverse/status/actions/workflows/update.yaml resolved the status issues. I suspect any lingering ones will clear out automatically.

[eitsupi]

Do not close this yet.

IIUC, if the problem is not resolved in the source repository by the deadline, the package will be removed from the production repository.
Doesn't this mean that downstream users will not be able to use the package with confidence?
The situation could even be worse than CRAN, given that such a problem could occur just before the day the freeze takes place.

[wlandau-lilly]

A dashboard could be built on top of this based on the files in https://github.com/r-multiverse/status or json in https://github.com/r-multiverse/staging/blob/main/issues.json, but we haven't built that, at least so far. Would be great to delegate this to someone if they're interested.

Actually, maybe https://github.com/r-multiverse/status could simply list all the problematic packages for each of Community and Staging? I will add an issue.

[wlandau-lilly]

Even in that case, it would be useful to have a dashboard to check which packages have passed.

For #140, I think a static page would suffice, and it may be more efficient and readable to list all the packages that are failing (presumably a shorter list). But otherwise, I think #140 can get at the same idea.

[shikokuchuo]

We do handle this at the R-multiverse level as best we can. However, R-universe may rerun checks periodically for other reasons: for example, a new patched version of R. @jeroen may be able to elaborate on this.

But once a package passes checks in Staging, it's SHA is fixed and should just proceed to Production. Only those with an outstanding issue would be affected by these re-run checks - once they pass checks, they should also be fixed?

[wlandau]

But once a package passes checks in Staging, it's SHA is fixed and should just proceed to Production.

Unless there is a problem in the next round of R-universe checks, which may be triggered for different reasons. That could cause a previously passing package to fail.

Do we want to forcibly guarantee admission into Production the first time a release passes in Staging. This is appealing, but we would need to think about the consequences.

[wlandau]

Just posted #141. I hope we can eliminate maintainer anxiety about packages suddenly breaking in Staging, while also keeping the existing system clean and consistent.

[wlandau]

@eitsupi, we talked about this issue in the last admin meeting, and we agreed that a package that passes once in Staging should be guaranteed a spot in Production. I implemented this in multiverse.internals 0.4.0.

[wlandau]

https://r-multiverse.org/status should show which packages make it into the snapshot. I opened an issue: #152. This will make it easier to explain to package maintainers.

[wlandau]

I added a commit in wlandau/r-multiverse.github.io@c2ae51c to refer contributors to https://r-multiverse.org/status/production.html to see if their packages made it into Production.

[eitsupi]

Thanks for working on that, looks good!
I think we can close this discussion since improvements have already been made in various areas.

[wlandau]

Sounds great. And hopefully with r-multiverse/r-multiverse.github.io#57, the Staging process will be even more dependable and predictable. I really like how it's coming together, and I think it will make things really smooth for maintainers.

[wlandau]

By the way, r-multiverse/r-multiverse.github.io#57 supersedes r-multiverse/r-multiverse.github.io#56