Skip to content

[Bioc-devel] Policies regarding forked packages

5 messages · Leonardo Collado Torres, Alexey Sergushichev, Henrik Bengtsson +2 more

Leonardo Collado Torres
# 
Hi,

I'm not from Bioconductor core. Just a heads up that they've been busy
with the BioC 3.20 release that was just recently completed
https://bioconductor.org/news/bioc_3_20_release/.
community by keeping your fork in working conditions. From
https://github.com/Bioconductor/Contributions/issues/new I don't see
any specific info about your question. Searching "fork" at
https://contributions.bioconductor.org/index.html also didn't lead me
to any relevant results.

Best,
Leo

Leonardo Collado Torres, Ph. D.
Investigator, LIEBER INSTITUTE for BRAIN DEVELOPMENT
Assistant Professor, Department of Biostatistics
Johns Hopkins Bloomberg School of Public Health
855 N. Wolfe St., Room 382
Baltimore, MD 21205
lcolladotor.github.io
lcolladotor at gmail.com

Leonardo Collado Torres, Ph. D.
Investigator, LIEBER INSTITUTE for BRAIN DEVELOPMENT
Assistant Professor, Department of Biostatistics
Johns Hopkins Bloomberg School of Public Health
855 N. Wolfe St., Room 382
Baltimore, MD 21205
lcolladotor.github.io
lcolladotor at gmail.com



On Mon, Oct 28, 2024 at 9:39?AM Ali Sajid Imami
<ali.sajid.imami at gmail.com> wrote:
Alexey Sergushichev
# 
Hi,

I also would add that it could make sense to rename your fork. I understand
this is a normal practice in open source software, that you start a new
project by forking an old one, but unless you have an explicit permission
to use the original package name, I'm not sure using it is ethically or
legally correct. When you have your own package name, the MIT licence
allows you to use the old code.

Best,
Aexey

On Fri, Nov 1, 2024 at 11:06?AM Leonardo Collado Torres <
lcolladotor at gmail.com> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Henrik Bengtsson
    

    

      
      #
    

  


  

      
FWIW, the CRAN Repository Policies
(https://cran.r-project.org/web/packages/policies.html) has the below
regarding "takeovers". Maybe Bioconductor can borrow from this.

"Packages should be named in a way that does not conflict
(irrespective of case) with any current or past CRAN package (the
Archive area can be consulted), nor any current Bioconductor package.
Package maintainers give the right to use that package name to CRAN
when they submit, so the CRAN team may orphan a package and allow
another maintainer to take it over. Package names on CRAN are
persistent and in general it is not permitted to change a package?s
name.

When a new maintainer wishes to take over a package, this should be
accompanied by the written agreement of the previous maintainer
(unless the package has been formally orphaned)."

This covers takeover of a package that has been orphaned.  CRAN uses:

Maintainer: ORPHANED

to formally mark a package orphaned, e.g.
https://github.com/search?q=org%3Acran+Maintainer%3A+ORPHANED&type=code

R CMD check with _R_CHECK_ORPHANED_=true gives an alert (NOTE or
WARNING?) package that directly or indirectly depend on an orphaned
package.

The CRAN Policies doesn't say how and when CRAN decides to orphan a
package.  My guess is that they might do it when they noticed that the
maintainer does not respond to their requests, or the maintainer's
email address bounces. OTH, we
(https://www.cranhaven.org/dashboard-live.html) also see that they end
up archiving all-OK packages when the maintainer does not respond,
e.g. https://cran.r-project.org/package=SACCR.

Although not explicitly stated, CRAN has the power to orphan a
package, and *orphaned* packages can be taken over per the above
policies. They don't write anything explicit about taking over
*archived*, non-orphaned packages, but I guess that can declare a
package that has been archived for a "long time" to be orphaned, and
thereby allow someone to take it over.

/Henrik

        
On Fri, Nov 1, 2024 at 9:46?AM Alexey Sergushichev <alsergbox at gmail.com> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    
5 days later

    

      
      

        


  

        

      Shepherd, Lori
    

    

      
      #
    

  


  

      
FWIW: Bioconductor does follow CRAN policy except we do not change or have a tag for "orphaned" packages.   We consider an unmaintained package that is failing in this category so anything that is up for deprecation/removal and if someone is trying to reach the maintainer and they remain unresponsive or we find the email is no longer active but currently don't have a maintainer validity check.  A maintainer validity check is on my list of projects for the next year and hope to have better policy around it soon.

https://contributions.bioconductor.org/package-end-of-life-policy.html#orphaned-packages




Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Lluís Revilla
    

    

      
      #
    

  


  

      
Dear Lori,

In light of the time burden that the Bioconductor core team has: Does this
project for "a maintainer validity check " require specific permissions or
internal expertise?
Could someone from the community contribute or help to get it done
(hopefully sooner)?

For instance with Henrik, we have a website that warns when CRAN packages
are about to be archived (https://www.cranhaven.org/).
If Bioconductor considers these Orphaned packages and removes them in the
following release it could be something I (we) would be interested in.

Best,

Llu?s

On Thu, 7 Nov 2024 at 14:26, Kern, Lori via Bioc-devel <

        
bioc-devel at r-project.org> wrote: