[Bioc-devel] plyranges maintainer update

2024-04-05 Thread Stuart Lee 
Hi bioc-devel,

I would like to request for me to removed as maintainer of the plyranges
package 
and for > to be added as
maintainer.

Thank you for your help.

Kind regards,
Stuart


Stuart Lee
stuart.andrew@gmail.com

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] duplicated entries with 'ExperimentHub(localHub=TRUE)'

2024-04-05 Thread Levi Waldron 
Nice example of a reproducible bug report and rapid bug-fix!

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] duplicated entries with 'ExperimentHub(localHub=TRUE)'

2024-04-05 Thread Kern, Lori via Bioc-devel 
Of Note:  The fix actually occurs in the AnnotationHub code base.  It has been 
pushed to both release and devel.


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Robert Castelo 
Sent: Friday, April 5, 2024 9:22 AM
To: Kern, Lori 
Cc: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] duplicated entries with 'ExperimentHub(localHub=TRUE)'


that's great, thank you so much Lori!


robert.


On 4/5/24 15:02, Kern, Lori wrote:
I found the bug.  Testing and pushing up a fix.

Cheers,


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel 
 on 
behalf of Kern, Lori via Bioc-devel 

Sent: Friday, April 5, 2024 8:15 AM
To: Robert Castelo ; 
bioc-devel@r-project.org 

Subject: Re: [Bioc-devel] duplicated entries with 'ExperimentHub(localHub=TRUE)'

I will have to look at how offline changes the loading of the files.  That is 
an odd and unexpected behavior.

They aren't actually duplicate files, what is happening is it is displaying the 
entry for the bam file (.bam) and the index file (.bai) as separate entries 
when offline instead of associating them as one entry.

I'll investigate more.


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel 
 on 
behalf of Robert Castelo 
Sent: Thursday, April 4, 2024 2:40 PM
To: bioc-devel@r-project.org 

Subject: [Bioc-devel] duplicated entries with 'ExperimentHub(localHub=TRUE)'

hi,

I'm getting duplicated entries when loading **offline** previously
cached ExperimentHub resources. This code reproduces the problem:

1. If in a fresh empty cache of ExperimentHub I download 9 resources
through the gDNAinRNAseqData package:

library(gDNAinRNAseqData)

bamfiles <- LiYu22subsetBAMfiles()
length(bamfiles)
[1] 9

2. Try to load them again from the local cache either going offline or
using the 'offline=TRUE' argument to the loader function, which sets
'localHub=TRUE' in the call to 'ExperimentHub()':

bamfiles <- LiYu22subsetBAMfiles(offline=TRUE)
Using 'localHub=TRUE'
   If offline, please also see BiocManager vignette section on offline use
snapshotDate(): 2024-04-02
see ?gDNAinRNAseqData and browseVignettes('gDNAinRNAseqData') for
documentation
loading from cache
[...]

length(bamfiles)
[1] 18

3. If I examine the resources offline directly with 'ExperimentHub()' I
see them duplicated with some IDs getting a '.1' suffix:

library(ExperimentHub)

eh <- ExperimentHub(localHub=TRUE)
Using 'localHub=TRUE'
   If offline, please also see BiocManager vignette section on offline use
snapshotDate(): 2024-04-02
length(eh)
[1] 18
eh
ExperimentHub with 18 records
# snapshotDate(): 2024-04-02
# $dataprovider: NGDC
# $species: Homo sapiens
# $rdataclass: BamFile
# additional mcols(): taxonomyid, genome, description,
#   coordinate_1_based, maintainer, rdatadateadded, preparerclass, tags,
#   rdatapath, sourceurl, sourcetype
# retrieve records with, e.g., 'object[["EH8079"]]'


   EH8079   |
   EH8079.1 |
   EH8080   |
   EH8080.1 |
   EH8081   |
   ...
   EH8085.1 |
   EH8086   |
   EH8086.1 |
   EH8087   |
   EH8087.1 |
title
   EH8079   RNA-seq data BAM file subset of HRR589632 contaminated with
0% gDNA
   EH8079.1 RNA-seq data BAM file subset of HRR589632 contaminated with
0% gDNA
   EH8080   RNA-seq data BAM file subset of HRR589633 contaminated with
0% gDNA
   EH8080.1 RNA-seq data BAM file subset of HRR589633 contaminated with
0% gDNA
   EH8081   RNA-seq data BAM file subset of HRR589634 contaminated with
0% gDNA
   ... ...
   EH8085.1 RNA-seq data BAM file subset of HRR589623 contaminated with
10% ...
   EH8086   RNA-seq data BAM file subset of HRR589624 contaminated with
10% ...
   EH8086.1 RNA-seq data BAM file subset of HRR589624 contaminated with
10% ...
   EH8087   RNA-seq data BAM file subset of HRR589625 contaminated with
10% ...
   EH8087.1 RNA-seq data BAM file subset of HRR589625 contaminated with
10% ...

Does anybody have an idea what might be going on with
'ExperimentHub(localHub=TRUE)'?

Thanks!

robert.

___
Bioc-devel@r-project.org mailing list

Re: [Bioc-devel] duplicated entries with 'ExperimentHub(localHub=TRUE)'

2024-04-05 Thread Robert Castelo 
that's great, thank you so much Lori!


robert.


On 4/5/24 15:02, Kern, Lori wrote:
> I found the bug.  Testing and pushing up a fix.
>
> Cheers,
>
> Lori Shepherd - Kern
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> *From:* Bioc-devel  on behalf of 
> Kern, Lori via Bioc-devel 
> *Sent:* Friday, April 5, 2024 8:15 AM
> *To:* Robert Castelo ; 
> bioc-devel@r-project.org 
> *Subject:* Re: [Bioc-devel] duplicated entries with 
> 'ExperimentHub(localHub=TRUE)'
> I will have to look at how offline changes the loading of the files.  
> That is an odd and unexpected behavior.
>
> They aren't actually duplicate files, what is happening is it is 
> displaying the entry for the bam file (.bam) and the index file (.bai) 
> as separate entries when offline instead of associating them as one entry.
>
> I'll investigate more.
>
>
> Lori Shepherd - Kern
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Bioc-devel  on behalf of 
> Robert Castelo 
> Sent: Thursday, April 4, 2024 2:40 PM
> To: bioc-devel@r-project.org 
> Subject: [Bioc-devel] duplicated entries with 
> 'ExperimentHub(localHub=TRUE)'
>
> hi,
>
> I'm getting duplicated entries when loading **offline** previously
> cached ExperimentHub resources. This code reproduces the problem:
>
> 1. If in a fresh empty cache of ExperimentHub I download 9 resources
> through the gDNAinRNAseqData package:
>
> library(gDNAinRNAseqData)
>
> bamfiles <- LiYu22subsetBAMfiles()
> length(bamfiles)
> [1] 9
>
> 2. Try to load them again from the local cache either going offline or
> using the 'offline=TRUE' argument to the loader function, which sets
> 'localHub=TRUE' in the call to 'ExperimentHub()':
>
> bamfiles <- LiYu22subsetBAMfiles(offline=TRUE)
> Using 'localHub=TRUE'
>    If offline, please also see BiocManager vignette section on offline use
> snapshotDate(): 2024-04-02
> see ?gDNAinRNAseqData and browseVignettes('gDNAinRNAseqData') for
> documentation
> loading from cache
> [...]
>
> length(bamfiles)
> [1] 18
>
> 3. If I examine the resources offline directly with 'ExperimentHub()' I
> see them duplicated with some IDs getting a '.1' suffix:
>
> library(ExperimentHub)
>
> eh <- ExperimentHub(localHub=TRUE)
> Using 'localHub=TRUE'
>    If offline, please also see BiocManager vignette section on offline use
> snapshotDate(): 2024-04-02
> length(eh)
> [1] 18
> eh
> ExperimentHub with 18 records
> # snapshotDate(): 2024-04-02
> # $dataprovider: NGDC
> # $species: Homo sapiens
> # $rdataclass: BamFile
> # additional mcols(): taxonomyid, genome, description,
> #   coordinate_1_based, maintainer, rdatadateadded, preparerclass, tags,
> #   rdatapath, sourceurl, sourcetype
> # retrieve records with, e.g., 'object[["EH8079"]]'
>
>
>    EH8079   |
>    EH8079.1 |
>    EH8080   |
>    EH8080.1 |
>    EH8081   |
>    ...
>    EH8085.1 |
>    EH8086   |
>    EH8086.1 |
>    EH8087   |
>    EH8087.1 |
> title
>    EH8079   RNA-seq data BAM file subset of HRR589632 contaminated with
> 0% gDNA
>    EH8079.1 RNA-seq data BAM file subset of HRR589632 contaminated with
> 0% gDNA
>    EH8080   RNA-seq data BAM file subset of HRR589633 contaminated with
> 0% gDNA
>    EH8080.1 RNA-seq data BAM file subset of HRR589633 contaminated with
> 0% gDNA
>    EH8081   RNA-seq data BAM file subset of HRR589634 contaminated with
> 0% gDNA
>    ... ...
>    EH8085.1 RNA-seq data BAM file subset of HRR589623 contaminated with
> 10% ...
>    EH8086   RNA-seq data BAM file subset of HRR589624 contaminated with
> 10% ...
>    EH8086.1 RNA-seq data BAM file subset of HRR589624 contaminated with
> 10% ...
>    EH8087   RNA-seq data BAM file subset of HRR589625 contaminated with
> 10% ...
>    EH8087.1 RNA-seq data BAM file subset of HRR589625 contaminated with
> 10% ...
>
> Does anybody have an idea what might be going on with
> 'ExperimentHub(localHub=TRUE)'?
>
> Thanks!
>
> robert.
>
> ___
> Bioc-devel@r-project.org mailing list
> https://secure-web.cisco.com/1H0voxA7oQ0saDcNCWmRZwr1H6rkyUr0Fu4Ru-hZrq5GY1ay-R4ltvl_raeo94HUjjlKMox7wMWOkNHrqW28aJmsFXxCkYVatvRWHo5X5Pwpy3KKZLPxRybRw-xB-pjeKV38ia8MSC3_WURYilKunRSCMrcU8O0rBmThSR5Zip-TpfdAvp5oTkjIvudwgfsDPkVYxWwfoZIAFgRMj1x0D6yNG-HAsH5z4ejKrUklBnDvDPDK60h8e8HX0O31gA3pKSQYcN4v71RUYobDgAeciTZJwFe7PVneGo5q2nBuXNIhkwzKebrB5H9_O2At40PjQ9NOAKYCnl4N532p-NNGkHw/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
>
>
>
> This email message may contain legally privileged and/or confidential 
> information.  If you are not the intended recipient(s), or the 
> employee or agent responsible for the delivery of this message to the 
> intended

Re: [Bioc-devel] duplicated entries with 'ExperimentHub(localHub=TRUE)'

2024-04-05 Thread Kern, Lori via Bioc-devel 
I found the bug.  Testing and pushing up a fix.

Cheers,


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Kern, Lori via 
Bioc-devel 
Sent: Friday, April 5, 2024 8:15 AM
To: Robert Castelo ; bioc-devel@r-project.org 

Subject: Re: [Bioc-devel] duplicated entries with 'ExperimentHub(localHub=TRUE)'

I will have to look at how offline changes the loading of the files.  That is 
an odd and unexpected behavior.

They aren't actually duplicate files, what is happening is it is displaying the 
entry for the bam file (.bam) and the index file (.bai) as separate entries 
when offline instead of associating them as one entry.

I'll investigate more.


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Robert Castelo 

Sent: Thursday, April 4, 2024 2:40 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] duplicated entries with 'ExperimentHub(localHub=TRUE)'

hi,

I'm getting duplicated entries when loading **offline** previously
cached ExperimentHub resources. This code reproduces the problem:

1. If in a fresh empty cache of ExperimentHub I download 9 resources
through the gDNAinRNAseqData package:

library(gDNAinRNAseqData)

bamfiles <- LiYu22subsetBAMfiles()
length(bamfiles)
[1] 9

2. Try to load them again from the local cache either going offline or
using the 'offline=TRUE' argument to the loader function, which sets
'localHub=TRUE' in the call to 'ExperimentHub()':

bamfiles <- LiYu22subsetBAMfiles(offline=TRUE)
Using 'localHub=TRUE'
   If offline, please also see BiocManager vignette section on offline use
snapshotDate(): 2024-04-02
see ?gDNAinRNAseqData and browseVignettes('gDNAinRNAseqData') for
documentation
loading from cache
[...]

length(bamfiles)
[1] 18

3. If I examine the resources offline directly with 'ExperimentHub()' I
see them duplicated with some IDs getting a '.1' suffix:

library(ExperimentHub)

eh <- ExperimentHub(localHub=TRUE)
Using 'localHub=TRUE'
   If offline, please also see BiocManager vignette section on offline use
snapshotDate(): 2024-04-02
length(eh)
[1] 18
eh
ExperimentHub with 18 records
# snapshotDate(): 2024-04-02
# $dataprovider: NGDC
# $species: Homo sapiens
# $rdataclass: BamFile
# additional mcols(): taxonomyid, genome, description,
#   coordinate_1_based, maintainer, rdatadateadded, preparerclass, tags,
#   rdatapath, sourceurl, sourcetype
# retrieve records with, e.g., 'object[["EH8079"]]'


   EH8079   |
   EH8079.1 |
   EH8080   |
   EH8080.1 |
   EH8081   |
   ...
   EH8085.1 |
   EH8086   |
   EH8086.1 |
   EH8087   |
   EH8087.1 |
title
   EH8079   RNA-seq data BAM file subset of HRR589632 contaminated with
0% gDNA
   EH8079.1 RNA-seq data BAM file subset of HRR589632 contaminated with
0% gDNA
   EH8080   RNA-seq data BAM file subset of HRR589633 contaminated with
0% gDNA
   EH8080.1 RNA-seq data BAM file subset of HRR589633 contaminated with
0% gDNA
   EH8081   RNA-seq data BAM file subset of HRR589634 contaminated with
0% gDNA
   ... ...
   EH8085.1 RNA-seq data BAM file subset of HRR589623 contaminated with
10% ...
   EH8086   RNA-seq data BAM file subset of HRR589624 contaminated with
10% ...
   EH8086.1 RNA-seq data BAM file subset of HRR589624 contaminated with
10% ...
   EH8087   RNA-seq data BAM file subset of HRR589625 contaminated with
10% ...
   EH8087.1 RNA-seq data BAM file subset of HRR589625 contaminated with
10% ...

Does anybody have an idea what might be going on with
'ExperimentHub(localHub=TRUE)'?

Thanks!

robert.

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1H0voxA7oQ0saDcNCWmRZwr1H6rkyUr0Fu4Ru-hZrq5GY1ay-R4ltvl_raeo94HUjjlKMox7wMWOkNHrqW28aJmsFXxCkYVatvRWHo5X5Pwpy3KKZLPxRybRw-xB-pjeKV38ia8MSC3_WURYilKunRSCMrcU8O0rBmThSR5Zip-TpfdAvp5oTkjIvudwgfsDPkVYxWwfoZIAFgRMj1x0D6yNG-HAsH5z4ejKrUklBnDvDPDK60h8e8HX0O31gA3pKSQYcN4v71RUYobDgAeciTZJwFe7PVneGo5q2nBuXNIhkwzKebrB5H9_O2At40PjQ9NOAKYCnl4N532p-NNGkHw/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list

Re: [Bioc-devel] duplicated entries with 'ExperimentHub(localHub=TRUE)'

2024-04-05 Thread Kern, Lori via Bioc-devel 
I will have to look at how offline changes the loading of the files.  That is 
an odd and unexpected behavior.

They aren't actually duplicate files, what is happening is it is displaying the 
entry for the bam file (.bam) and the index file (.bai) as separate entries 
when offline instead of associating them as one entry.

I'll investigate more.


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Robert Castelo 

Sent: Thursday, April 4, 2024 2:40 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] duplicated entries with 'ExperimentHub(localHub=TRUE)'

hi,

I'm getting duplicated entries when loading **offline** previously
cached ExperimentHub resources. This code reproduces the problem:

1. If in a fresh empty cache of ExperimentHub I download 9 resources
through the gDNAinRNAseqData package:

library(gDNAinRNAseqData)

bamfiles <- LiYu22subsetBAMfiles()
length(bamfiles)
[1] 9

2. Try to load them again from the local cache either going offline or
using the 'offline=TRUE' argument to the loader function, which sets
'localHub=TRUE' in the call to 'ExperimentHub()':

bamfiles <- LiYu22subsetBAMfiles(offline=TRUE)
Using 'localHub=TRUE'
   If offline, please also see BiocManager vignette section on offline use
snapshotDate(): 2024-04-02
see ?gDNAinRNAseqData and browseVignettes('gDNAinRNAseqData') for
documentation
loading from cache
[...]

length(bamfiles)
[1] 18

3. If I examine the resources offline directly with 'ExperimentHub()' I
see them duplicated with some IDs getting a '.1' suffix:

library(ExperimentHub)

eh <- ExperimentHub(localHub=TRUE)
Using 'localHub=TRUE'
   If offline, please also see BiocManager vignette section on offline use
snapshotDate(): 2024-04-02
length(eh)
[1] 18
eh
ExperimentHub with 18 records
# snapshotDate(): 2024-04-02
# $dataprovider: NGDC
# $species: Homo sapiens
# $rdataclass: BamFile
# additional mcols(): taxonomyid, genome, description,
#   coordinate_1_based, maintainer, rdatadateadded, preparerclass, tags,
#   rdatapath, sourceurl, sourcetype
# retrieve records with, e.g., 'object[["EH8079"]]'


   EH8079   |
   EH8079.1 |
   EH8080   |
   EH8080.1 |
   EH8081   |
   ...
   EH8085.1 |
   EH8086   |
   EH8086.1 |
   EH8087   |
   EH8087.1 |
title
   EH8079   RNA-seq data BAM file subset of HRR589632 contaminated with
0% gDNA
   EH8079.1 RNA-seq data BAM file subset of HRR589632 contaminated with
0% gDNA
   EH8080   RNA-seq data BAM file subset of HRR589633 contaminated with
0% gDNA
   EH8080.1 RNA-seq data BAM file subset of HRR589633 contaminated with
0% gDNA
   EH8081   RNA-seq data BAM file subset of HRR589634 contaminated with
0% gDNA
   ... ...
   EH8085.1 RNA-seq data BAM file subset of HRR589623 contaminated with
10% ...
   EH8086   RNA-seq data BAM file subset of HRR589624 contaminated with
10% ...
   EH8086.1 RNA-seq data BAM file subset of HRR589624 contaminated with
10% ...
   EH8087   RNA-seq data BAM file subset of HRR589625 contaminated with
10% ...
   EH8087.1 RNA-seq data BAM file subset of HRR589625 contaminated with
10% ...

Does anybody have an idea what might be going on with
'ExperimentHub(localHub=TRUE)'?

Thanks!

robert.

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1H0voxA7oQ0saDcNCWmRZwr1H6rkyUr0Fu4Ru-hZrq5GY1ay-R4ltvl_raeo94HUjjlKMox7wMWOkNHrqW28aJmsFXxCkYVatvRWHo5X5Pwpy3KKZLPxRybRw-xB-pjeKV38ia8MSC3_WURYilKunRSCMrcU8O0rBmThSR5Zip-TpfdAvp5oTkjIvudwgfsDPkVYxWwfoZIAFgRMj1x0D6yNG-HAsH5z4ejKrUklBnDvDPDK60h8e8HX0O31gA3pKSQYcN4v71RUYobDgAeciTZJwFe7PVneGo5q2nBuXNIhkwzKebrB5H9_O2At40PjQ9NOAKYCnl4N532p-NNGkHw/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Important Bioconductor Release Deadlines

2024-04-05 Thread Kern, Lori via Bioc-devel 
It is also important to note that R-devel is available throughout this last 6 
months since the previous 3.18 release.  Out devel branch has been building 
against it all along. It is available via direct download, dockers, github 
actions, etc.  That is why we have the two branches of Bioconductor devel and 
release so that errors can appear as soon as possible and so maintainers can be 
aware of potential changes in R that could affect their package.

org and ontology objects can change frequently which is why we release new 
versions each release.  We add them closer to the release so that the packages 
can have as recent data as possible while still giving maintainers time to 
adapt.  We added them to the devel branch now so maintainers would have 4-6 
weeks to correct the errors.

Also regarding tying R and Bioconductor version. Emphasizing how we would 
possible test to ensure that code and changes would work on past versions.  As 
previously stated,  it has occurred that changes in R are not backwards 
compatible and could cause trouble (mainly between the jump from 3.6 to 4.0).  
We need to have versions of packages that can work for its given version.  
Maybe as we look at more github action type solutions we would test on more 
versions but this means extra onus on maintainers to make sure code can work 
regardless of version which sometimes can be more challenging. CRAN is also has 
a more strict policy as they test across different versions and if it fails on 
a previous version of R that a package would be up for removal (at least that 
is my understanding).

Lastly, A package won't be excluded from a release if it is encountering new 
errors.  We always allow a few weeks leeway and multiple communications before 
we would consider marking a package for deprecation. Even after that,  as long 
as a maintainer fixes the package before the next release it can be reinstated. 
We encourage maintainer to fix before the release else they would have to push 
to the two branches of Bioconductor so we are trying to minimize the effort to 
fix errors.   As stated, if we delay a release or the package is failing at 
release time delays the availability of the package to users for the latest 
release of R.

Cheers,


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Vincent Carey 

Sent: Friday, April 5, 2024 6:51 AM
To: Anatoly Sorokin 
Cc: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] Important Bioconductor Release Deadlines

On Fri, Apr 5, 2024 at 12:56 AM Anatoly Sorokin  wrote:
>
> Dear Levi,
>
> minor correction: not requiring but working with. Testing against r-devel
> and requiring it for development are two different things. If the
> development and maintenance of the Bioconductor package would be my only
> responsibility, I wouldn't argue. But because this is a voluntary activity
> additional restrictions such as maintaining unstable software release,
> which is not needed at all, make it less attractive.
>
> In my mind, the requirements mean that the software is not backwards
> compatible any more. In my experience, cases when packages are not working
> with an R older in major release is rare (for example at the moment all my
> code working with R 3.6, due to limitations on some collaborator's
> systems). I haven't checked but it would be really interesting to run R Cmd
> check on 3.19 packages with R 4.0 and find how many of them will fail.
>
> When we were deciding how to release our code Bioconductor was chosen due
> to its stability and user-friendliness in package and dependencies
> installation, which is crucial for the adoption of the analysis approach by
> biologists who are not so familiar with coding. Forcing them to completely
> reinstall the framework is not so convenient.
>
> But anyway it is just my thoughts.
>
> On Fri, Apr 5, 2024 at 12:39 PM Levi Waldron 
> wrote:
>
> > Anatoly, delaying dependency on R 4.4 until October would mean 6 months of
> > Bioconductor release requiring an old release of R for users. Bioconductor
> > developers developing against r-devel means that users get a new
> > Bioconductor release that works immediately on the new R. And I think a
> > main purpose of a 6 month devel and release cycle is to provide a
> > comfortable period for everyone to work out new features and bugs and to
> > resolve downstream consequences that may arise.  Delaying the Bioconductor
> > release by a week or something might actually encourage a habit of
> > last-week bug fixes that should be discouraged . I really can’t see any
> > way around requiring developers to test against r-devel without sacrificing
> > timeliness and reliability for users. There are also Docker and GitHub
> > Actions options that don’t require installing r-devel to test against it.
> >
>
> But the

Re: [Bioc-devel] Important Bioconductor Release Deadlines

2024-04-05 Thread Vincent Carey 
On Fri, Apr 5, 2024 at 12:56 AM Anatoly Sorokin  wrote:
>
> Dear Levi,
>
> minor correction: not requiring but working with. Testing against r-devel
> and requiring it for development are two different things. If the
> development and maintenance of the Bioconductor package would be my only
> responsibility, I wouldn't argue. But because this is a voluntary activity
> additional restrictions such as maintaining unstable software release,
> which is not needed at all, make it less attractive.
>
> In my mind, the requirements mean that the software is not backwards
> compatible any more. In my experience, cases when packages are not working
> with an R older in major release is rare (for example at the moment all my
> code working with R 3.6, due to limitations on some collaborator's
> systems). I haven't checked but it would be really interesting to run R Cmd
> check on 3.19 packages with R 4.0 and find how many of them will fail.
>
> When we were deciding how to release our code Bioconductor was chosen due
> to its stability and user-friendliness in package and dependencies
> installation, which is crucial for the adoption of the analysis approach by
> biologists who are not so familiar with coding. Forcing them to completely
> reinstall the framework is not so convenient.
>
> But anyway it is just my thoughts.
>
> On Fri, Apr 5, 2024 at 12:39 PM Levi Waldron 
> wrote:
>
> > Anatoly, delaying dependency on R 4.4 until October would mean 6 months of
> > Bioconductor release requiring an old release of R for users. Bioconductor
> > developers developing against r-devel means that users get a new
> > Bioconductor release that works immediately on the new R. And I think a
> > main purpose of a 6 month devel and release cycle is to provide a
> > comfortable period for everyone to work out new features and bugs and to
> > resolve downstream consequences that may arise.  Delaying the Bioconductor
> > release by a week or something might actually encourage a habit of
> > last-week bug fixes that should be discouraged . I really can’t see any
> > way around requiring developers to test against r-devel without sacrificing
> > timeliness and reliability for users. There are also Docker and GitHub
> > Actions options that don’t require installing r-devel to test against it.
> >
>
> But the recent release of 3.19 version of GO.db package forced me to the
> last-minute bug fixing of the code, which was perfectly fine, anyway.
>
> >
> > I think many HPC clusters now support Singularity, which is a more
> > reliable and easier way to run packages with a compatible version of R.
> > Installing from GitHub on an old version of R has no guarantees of being
> > tested or working correctly even if it installs without error, and I see as
> > a sacrifice of software reliability for convenience that can be avoided
> > with Singularity or regular R updates.
> >
>
> That's why each package should contain a reliable set of tests. And again,
> regular updates of the R are fine for the self-managed machines and skilful
> users. Don't fix something, which works!
>
> >
> > Henrik, if Bioconductor releases weren’t tied to R releases, how could
> > Bioconductor test them? I guess like CRAN where as long as a package says
> > it depends on R >= 2.0 then you’re free to try installing on 2.0 even
> > though the combination has never been tested? Maybe I worry too much about
> > such testing since CRAN seems OK anyways, as far as we know?
> >
> My point is that too-tight ties make Bioconductor less reliable. When you
> test your code against someone's unstable release you are wasting your
> time, since you have to debug not only your code but the unstable version
> of the platform. I did not sign up as an R beta tester.

Hi Anatoly, sorry to hear about your issue, and I would like to understand more
about the specific technical problem you've encountered.  Maybe we can take
that off line to the developer forum channel in our slack.

On not signing up "as an R beta tester", it may be worth thinking about the
following:  One of the values of participating in an open source community as a
user is the opportunity afforded to "give back" to the many projects
that underlie
any reasonably complex open source tool of interest.  Since the
inception of Bioconductor, I
would say, it is realized that the project is wholly dependent not just upon R
as a language at any given time, but on the evolution of R and CRAN.  Ideas
from Bioconductor such as "vignettes" as package components and testing
resources were brought into R _from Bioconductor_.  R proved adaptable to
the interests of genomic data scientists, who needed vignettes
urgently around the
turn of the century.  Vignettes proved to be very generally valuable, of course,
but their role in packaging started with bioc.  R core members take advantage
of Bioconductor packages to enhance exploration of the surface of
potential language
problems, and "testing against Bioconductor" is a routine part of