llrs
commented
2 years ago Was exploring other things, and it might not be needed to modify any function. As the mirror of CRAN on github has this information on the DESCRIPTION files, for example:
Packaged: 2022-01-11 15:50:42 UTC; edd
Repository: CRANA simple scan of all the descriptions there will reveal which were last modified by CRAN.
Per a comment on this bug report 17530 opened by @wlandau it seems that there are some misunderstanding when CRAN modifies a package.
It is known that CRAN keeps the rights to modify the packages: "without notice or explanation (although notification will usually be given) ". In the event that a notification is given it is to the maintainer of the packages and not other maintainers and if those maintainers are unresponsive it is highly probable that this doesn't help.
However, for outsiders all this is invisible. They do not know that a packages has had some problems that CRAN decided to modify the package. This is due to for other CRAN maintainers and R users there is no "Packaged:" field displayed on CRAN so other maintainers do not know if a package is updated by the "Maintainer:" or somebody else (unless they download the tar.gz file and decide to explore the DESCRIPTION package). If they continue to build and depend on those packages that is more work for the CRAN team.
It would be nice to to keep track of those packages that have been updated by CRAN and report it so that package developers/maintainers know that that they can help or do not depend much on that package (in case CRAN decides to stop updating it). On some cases this might be before archiving (cf #8 ) is done but after reminders are sent, so this might work better to detect those packages that CRAN considers worth keeping but maintainers do not longer can/do.
This field could be added to those that write_PACKAGES and update_PACKAGES save/update that are at (if my guess is correct):
If the modification on those functions and addition of this field on those files is not possible a mirror of CRAN would be needed to explore each package.
This could have the benefit to highlight the CRAN work to keep up packages and also remove misunderstanding from other packages (nudge them towards other dependencies or become maintainers of said dependency). Of course, all this proposal depends on keeping the user on that field or similar solutions.