[Rd] Case: package removed from CRAN, but not orphaned

[Uwe Ligges]

On 25.11.2011 16:04, Rainer M Krug wrote:
> 2011/11/25 Uwe Ligges<ligges at statistik.tu-dortmund.de>
>
>> On 25.11.2011 11:56, Pfaff, Bernhard Dr. wrote:
>>
>>> Dear R-Devel subscriber,
>>>
>>> I would like to raise a topic and ask for your advice, guidance.
>>> Today on R-help an issue with a certain package popped up that has been
>>> removed from CRAN, because it failed the checks and/or the dependencies are
>>> not any longer available. The package maintainer has been alerted to this
>>> issue a couple of times and kindly asked to fix the code, such that it
>>> fullfills the CRAN requirements. However, neither a fix is applied, nor has
>>> the package been orphaned such that someone else could take over the
>>> ownership and rectify the package.
>>> In principal, and if I am not mistaken, one could simply take the code,
>>> fix it and release it (the package is under GPL-2). However, I would
>>> consider this as a rather rude approach. Hence, my question would be, if
>>> the R Core team can take the initiative, to declare the package as being
>>> orphaned after a 'warning period' has been elapsed in which the current
>>> maintainer is kindly asked to fix his package. Would it be feasible to ask
>>> R Core to orphan a package?
>>>
>>> Best,
>>> Bernhard
>>>
>>> ps: Incidentally, I am aware of the new 'orphaned package rules', in
>>> particular under the rubrique 'Possible reasons for orphanizing a package',
>>> point 2). In the case of the package in question, the maintainer does
>>> respond to emails, but either seems to lack action and/or has a different
>>> time scale and awareness of time.
>>>
>>
>>
>> As Duncan wrote already, CRAN is not run by R-core - as you probably know,
>> I have already maintained parts of CRAN for quite some time before I became
>> core member.
>>
>> Let me as one of the CRAN maintainers add:
>>
>> We know that orphaning would be a nice hint to the community, but it takes
>> some work and given we have>>  3000 packages, many of them not well
>> maintained, we have to archive or orphan many packages a year nowadays. Due
>> the already huge amount of work CRAN maintenance generates, we simply
>> cannot invest more time given the time constraints.
>>
>> Note that we archive packages if a maintainer asks us to do so or if the
>> maintainer is unresponsive on our requests to fix the package. Since we as
>> CRAN maintainers were unsuccessful to contact or convince the maintainer to
>> fix, we typically won't invest more time/work on such a package.
>>
>> Of course, if someone wants to take over an archived package and cannot
>> get a response from the maintainer (but first try to do so yourself!) then
>> a request to take over as maintainer can be sent to CRAN.
>>
>> Currently we are working on a new CRAN policy document that will soon be
>> published. This document may clarify some further questions and establishes
>> some stricter policies to reduce the workload of CRAN maintainers.
>>
>
> Just as an idea to make sure that CRAN only contains maintained packages
> with a maintainer who feels responsible: Would it be feasible to introduce
> a system, so that each year (or for each release of a new version of R) the
> maintainers are automatically contacted via email and must reply to have
> their packages included in the new spring cleaned version of CRAN?
> This
> process could be automated, including the email confirmations (like mailing
> list subscriptions) and the non-maintained packages could be relocated to a
> second CRAN or marked as "will be removed at next springclean"? This would
> make sure that CRAN contains only "active" packages.

1. There is no reason to remove well working packages.
2. Removing packages with many reverse dependencies just because the 
maintainers are not reacting on auto-messages is not feasible: it 
multiplies the work.

Best wishes,
Uwe Ligges



> Cheers,
>
> Rainer
>
>
>>
>> Best wishes,
>> Uwe Ligges
>>
>>
>>
>>
>>
>>
>>> *********************************************************************
>>> Confidentiality Note: The information contained in this ...{{dropped:10}}
>>>
>>> ______________________________**________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/**listinfo/r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel>
>>>
>>
>> ______________________________**________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/**listinfo/r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel>
>>
>
>
>