epartment of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
>
> From: Bioc-devel on behalf of Henrik
> Bengtsson
> Sent: Friday, November 1, 2024 2:26 PM
> To: Alexey Sergushichev
> Cc: bioc-devel
Bengtsson
Sent: Friday, November 1, 2024 2:26 PM
To: Alexey Sergushichev
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Policies regarding forked packages
FWIW, the CRAN Repository Policies
(https://secure-web.cisco.com/1lFLAjnYOFY0iw8-R
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
Archi
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
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/.
>From the sideline, it seems that you are doing a great service to the
community by keeping your fork in working
Hi,
I have a question about your policies regarding forked packages. There is a
package that some of our other packages depend on and is of interest to the
Bioconductor community that our lab did not create. However, the package was
never submitted to CRAN or BioConductor, and the original auth
