I agree that the file shows the _reasons_ but that is not the same as a _process_.
With the high volume of packages that the CRAN maintainers handle, an explicit procedure beyond "request it" is needed or should at least be spelled out. We have pushed everything CRAN-related else towards automation, verification, and formalization; this shouldn't be different. On Wed, Sep 21, 2016 at 12:53 PM, Andrew Redd <amr...@gmail.com> wrote: > The README states clearly that a package is orphaned under any of three > conditions: > > The Maintainer requests is. > The maintainer email bounces > The maintainer is unresponsive to requests regarding the package from CRAN > maintainers > > But I think that it is a good idea to include those conditions in the > manuals. > > On Wed, Sep 21, 2016 at 9:30 AM Max Kuhn <mxk...@gmail.com> wrote: >> >> The CRAN policy page >> (https://cran.r-project.org/web/packages/policies.html) implies that >> there is a formal procedure for orphaning a package but none is >> mentioned in the Extensions manual >> (https://cran.r-project.org/doc/manuals/r-devel/R-exts.html). >> >> This page (https://cran.r-project.org/src/contrib/Orphaned/README) >> implies that one would simply resubmit the package to CRAN with the >> text "ORPHANED" in the `Maintainer` field. >> >> Is this the case? >> >> If this is not documented somewhere, can it be added to the Extensions >> manual? >> >> Thanks, >> >> Max >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
