[R-pkg-devel] CRAN modifications of packages

Max Kuhn mxkuhn @end|ng |rom gm@||@com
Sun May 5 17:46:07 CEST 2019

Some other examples:


















On Fri, May 3, 2019 at 11:55 AM Max Kuhn <mxkuhn using gmail.com> wrote:
> I've noticed a trend in the last year of a CRAN maintainer making  modifications to packages without notification to the package authors or  the community. Some times these have been made during a submission [1] and,  in other cases, for existing packages [2]. In the latter case, we intuit  that there are some cases where the maintainers have not responded to  communications about required changes to existing versions.
> In some cases, the changes are minor (see rngtools example linked below)  but also come with a strict R version dependency on the *current* version.  This causes a considerable number of problems for these packages and their  reverse dependencies. Since the reasons for the changes are not public, it is unclear why they could not have been considerably less invasive.   The process of making these changes is in direct opposition to the CRAN  policies, such as
> > If for some reason the submission has to be made by someone else (for  example, a co-author) this needs to be explained, and the designated  maintainer will need to confirm the submission.
> > If an update will change the package’s API and hence affect packages  depending on it, it is expected that you will contact the maintainers of  affected packages and suggest changes, and give them time (at least 2  weeks, ideally more) to prepare updates before submitting your updated  package.
> It is understandable that the CRAN maintainers require package maintainers  to check reverse dependencies. There doesn't appear to be a good reason  that CRAN maintainers do not follow these rules.
> In the case where a package maintainer has not properly responded to a  substantive issue, it is unclear what should happen. This does put CRAN in  a bad position, but one would hope that minimally invasive changes be made  and that the impact on the reverse dependencies be measured and processed  like a normal CRAN submission.  In particular, the effect of making quadprog >= 3.6.0 has been significant due to failures to install  reverse dependencies.
> Perhaps some minimal changes to the process could be:
> 1. There should be some sort of visible status (analogous to ORPHANED)  that clearly indicates this has happened, so users can better understand  the context of the change. An update to any NEWS file would also be  appropriate.
> 2. CRAN should, at least temporarily, be listed as an author.
> 3. Reverse dependency authors who are affected are notified a priori.
> Has anyone else experienced similar situations and how did you deal with  the consequences of the changes?
> Examples
> [1] https://github.com/gdkrmr/dimRed/issues/27#issuecomment-437458488
> [2]
> https://github.com/cran/rngtools/commit/c9c036b18e0bf6f20afcab15a2b38083aaf62da7
> and
> https://github.com/cran/quadprog/commit/a559f064e20f803ab3ffde413e7686d9c6299083

More information about the R-package-devel mailing list