On 24.03.19 21:00, Neal Fultz wrote: > 3) Adopt package, push fixed one to CRAN - not sure what the exact process > is for un-orphaning, or if I would want to commit to maintaining it without > knowing more about why it was dropped and how much work it is to get it > passing. Eg if it were pathological solaris memory errors, I might have to > pass. Are there ways to see old automated CRAN checks on a package that was > abandoned? This approach obviously would benefit the community, but this is > probably not billable work.
How about asking your client if they are willing to (partially) fund somebody (does not have to be you) for getting the package back on CRAN? They could be added to the DESCRIPTION in turn. And it might be cheaper for them than rewriting the library or the application. As for process: I think you basically upload a new version with higher version number and updated "Maintainer" field. I have done this once for tikzDevice, but that was only orphaned and not archived. As for assessing the risks: Often the old checks are available for some time after archiving, but I cannot find them in this case. Running "R CMD check" on the two latest tarballs reveals only some NOTEs, though, the most serious one from my point of view is usage of 'rand()' via 'random_shuffle()' https://github.com/cran/maxent/blob/master/src/sgd.cpp#L77. Greetings Ralf -- Ralf Stubner Senior Software Engineer / Trainer daqana GmbH Dortustraße 48 14467 Potsdam T: +49 331 23 61 93 11 F: +49 331 23 61 93 90 M: +49 162 20 91 196 Mail: ralf.stub...@daqana.com Sitz: Potsdam Register: AG Potsdam HRB 27966 Ust.-IdNr.: DE300072622 Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze
signature.asc
Description: OpenPGP digital signature
______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
