Add `rworkflows` to test/document `GenomicRanges` in GitHub Actions

[bschilder]

I've added rworkflows as a means of rapidly finding out whether all checks are passing on GitHub Actions before changes are pushed upstream to Bioc. Also makes a pkgdown website for you (launched via GitHub Pages), and has options for containerised deployment to DockerHub.

CHANGES IN VERSION 1.51.5

NEW FEATURES

o Add `rworkflows` GitHub Action.
o Add `rworkflows` badger to README.

BUG FIXES

o Fix GRanges-class.Rd: \item{} --> \item{" "}
o Fix intra-range-methods.Rd: \item{} --> \item{" "}

All you need to do on your end is add GH token as a GH secret named "PAT_GITHUB" to the main repo. @vobencha @hpages

Thanks!, Brian

[hpages]

Hi @bschilder,

Please provide more context. I never heard about rworkflows before. What is it and why do you think GenomicRanges needs it?

Note that the R CMD check warnings about \item{} are due to a change in R devel and a fix for that has no business here (I'm actually considering a different fix but didn't have time to get to this yet). Also I'm not sure why this PR adds a .Rbuildignore and a .gitignore file, or adds https://github.com/Bioconductor/GenomicRanges and RoxygenNote: 7.2.3 to the DESCRIPTION file. Please focus your PR on the rworkflows thing only.

Thanks, H.

[bschilder]

Please provide more context. I never heard about rworkflows before. What is it and why do you think GenomicRanges needs it?

That's because it's new :) https://github.com/neurogenomics/rworkflows/

Preprint: https://www.researchsquare.com/article/rs-2399015/v1

A relevant excerpt from the preprint that I hope answers your question:

The rworkflows suite is not mutually exclusive to the package checking services provided by Bioc, which regularly run standardised checks on multiple OS. To the contrary, rworkflows fills an important gap for developers of Bioc packages who wish to comprehensively test their package before pushing to the upstream Bioc copy, as the upstream copy can take several days to rerun checks. Having an intermediate checking solution via GitHub provides feedback within minutes or hours, as opposed to days, thus greatly accelerating the development cycle. While Bioc does provide a dedicated Docker container with several prerequisite software installed (e.g. BiocManager, BiocCheck), these containers do not have any other Bioc packages installed. rworkflows in fact uses the Bioc Docker container as a base and then builds upon it to generate a package-specific containerised environment ready for distribution to users. This greatly speeds up the time it takes for any given user to successfully install and start using the developer's R package.

To summarise, I noticed GenomicRanges GitHub repo doesn't have any continuous integration currently implemented. rworkflows lets you know if there's issues (on any platform) before it gets distributed to users on Bioc.

Note that the R CMD check warnings about \item{} are due to a change in R devel and a fix for that has no business here (I'm actually considering a different fix but didn't have time to get to this yet). Also I'm not sure why this PR adds a .Rbuildignore and a .gitignore file, or adds https://github.com/Bioconductor/GenomicRanges and RoxygenNote: 7.2.3 to the DESCRIPTION file. Please focus your PR on the rworkflows thing only.

I added these other fixes as a courtesy simply because I noticed them as I was adding rworkflows. But if you have other solutions you'd rather implement I'd be happy to remove them for you.

Best, Brian

[hpages]

Thanks for the details.

rworkflows lets you know if there's issues (on any platform) before it gets distributed to users on Bioc

Our daily builds will actually catch issues before they get distributed to BioC users. Yes it takes a day or two between the moment an issue occurs in the package and the moment it shows up on the daily report, but, as the maintainer of the GenomicRanges package, I'm fine with that.

Please reduce the changes to what's strictly related to the rworkflows functionality that you are aiming for. A well focused PR will help me get a clearer idea of what's really involved. Thanks!

H.

[bschilder]

Our daily builds will actually catch issues before they get distributed to BioC users. Yes it takes a day or two between the moment an issue occurs in the package and the moment it shows up on the daily report, but, as the maintainer of the GenomicRanges package, I'm fine with that.

Right, but if it fails on Bioc, the package becomes unavailable until a new push is made. In your case, you're very fast when it comes to noticing email notifications from Bioc, making fixes, and pushing them upstream. Unfortunately, this is not the case with many developers who may take weeks to months to address the issue (I myself have been guilty of this!). In the meantime, users of the package are unable to install it. This is especially troublesome to those who primarily work on the Bioc devel branch, as I and other developers do. Having reliable GitHub Actions directly in your GitHub repo gives you an extra layer of protection to avoid those scenarios.

Please reduce the changes to what's strictly related to the rworkflows functionality that you are aiming for. A well focused PR will help me get a clearer idea of what's really involved. Thanks!

Sure, no problem, I'll change them back now.

Just for some more context, my intention was to pass off this PR to you whilst the rworkflows action was passing on all platforms, to minimise the work involved for you, as I know you're involved in many projects and must be quite busy. Apologies if making these extra changes caused more problems than they solved!

[hpages]

Right, but if it fails on Bioc, the package becomes unavailable until a new push is made.

Not exactly. If the package was available before an issue gets introduced to it, it remains available. In other words, we usually don't remove a package that is available, we only replace it with a new one (i.e. with a new version), but only if the new one passes BUILD and CHECK on the daily builds. For example, the build failure for BSgenome that you spotted and reported earlier today (thanks for that) had no impact whatsoever on the users or developers, because the previous versions of the package (1.66.1 in release and 1.67.1 in devel) remained available.

A package is unavailable only if it was broken "since day one", that is, typically since the day of the last BioC release. Yes, a few packages are in that situation, and we try to notify their maintainers. But if after a couple of months or more nothing has changed, this tends to be more because of negligence or indifference from the maintainer, rather than because the maintainer lacked the tools to detect the problem.

Sure, no problem, I'll change them back now.

Thanks!

[bschilder]

Not exactly. If the package was available before an issue gets introduced to it, it remains available. In other words, we usually don't remove a package that is available, we only replace it with a new one (i.e. with a new version), but only if the new one passes BUILD and CHECK on the daily builds. For example, the build failure for BSgenome that you spotted and reported earlier today (thanks for that) had no impact whatsoever on the users or developers, because the previous versions of the package (1.66.1 in release and 1.67.1 in devel) remained available.

I'm a bit confused by this, as it seems to be the opposite of my experience. The only reason I found out BSgenome is failing is bc I couldn't install it on the GHA virtual machines, on Linux or Mac, or on Bioc devel or release. https://github.com/neurogenomics/MungeSumstats/actions/runs/3847722518/jobs/6554542793#step:4:1002

  Error: 
  ! error in pak subprocess
  Caused by error: 
  ! Cannot install packages:
  * deps::.:
    * Can't install dependency SNPlocs.Hsapiens.dbSNP155.GRCh37
    * Can't install dependency SNPlocs.Hsapiens.dbSNP155.GRCh38
  * SNPlocs.Hsapiens.dbSNP155.GRCh37: Can't install dependency BSgenome
  * SNPlocs.Hsapiens.dbSNP155.GRCh38: Can't install dependency BSgenome

I've encountered this same scenario many times now across different packages failing on Bioc at different times. I'd say maybe it's the installer being used, but I've noticed it regardless of whether I'm using BiocManager,install.packages (with bioc repos specified), AnVILor pak. Each time the packages failed to install bc they (or some package they depends on) were failing on Bioc, which I confirmed by checking their respective Bioc pages. And as soon as they said "passing" again on Bioc, they worked right away. Am I missing something here?

[hpages]

Well, in this particular case, the story is a little bit more complicated, sorry.

The "Can't install dependency BSgenome" message that you get in the GHA log is actually kind of misleading. BSgenome is available and can be installed (you can easily check that by trying to install it on your machine with BiocManager::install()).

However, about 2-3 days ago, I made available new versions of data packages SNPlocs.Hsapiens.dbSNP155.GRCh38 and SNPlocs.Hsapiens.dbSNP155.GRCh37 that require a version of BSgenome that is not available yet. See https://github.com/Bioconductor/BSgenome/issues/57. This was not a good idea, and I'm sorry for that. Note that the mistake is more about me making available new data packages that have impossible dependencies than about the BSgenome package itself.

Since those 2 SNPlocs packages are very big and it takes hours to propagate them to the public repos, and since it was a temporary situation anyways (it should resolve tomorrow), I thought I would just leave it as-is instead of trying to roll the packages back to their previous versions.

In other words, you would have gotten this GHA error even if the new version of BSgenome had not failed on our daily builds. But it's true that the fact that it failed delayed its propagation by a day or two, making it more likely for users or developers who try to install SNPlocs.Hsapiens.dbSNP155.GRCh38 or SNPlocs.Hsapiens.dbSNP155.GRCh37 to run into this impossible dependency problem.

So I need to take back my claim that the BSgenome build failure that you reported had no impact whatsoever on the users or developers. It didn't cause the impossible dependency problem but it prolonged it by one days or two. That is the impact.

BTW it doesn't help that the GHA log doesn't display more information about why installation of the 2 SNPlocs packages failed. This makes it almost impossible to understand the real reason why it failed.

[bschilder]

Well, in this particular case, the story is a little bit more complicated, sorry.

The "Can't install dependency BSgenome" message that you get in the GHA log is actually kind of misleading. BSgenome is available and can be installed (you can easily check that by trying to install it on your machine with BiocManager::install()).

However, about 2-3 days ago, I made available new versions of data packages SNPlocs.Hsapiens.dbSNP155.GRCh38 and SNPlocs.Hsapiens.dbSNP155.GRCh37 that require a version of BSgenome that is not available yet. See Bioconductor/BSgenome#57. This was not a good idea, and I'm sorry for that. Note that the mistake is more about me making available new data packages that have impossible dependencies than about the BSgenome package itself.

Since those 2 SNPlocs packages are very big and it takes hours to propagate them to the public repos, and since it was a temporary situation anyways (it should resolve tomorrow), I thought I would just leave it as-is instead of trying to roll the packages back to their previous versions.

In other words, you would have gotten this GHA error even if the new version of BSgenome had not failed on our daily builds. But it's true that the fact that it failed delayed its propagation by a day or two, making it more likely for users or developers who try to install SNPlocs.Hsapiens.dbSNP155.GRCh38 or SNPlocs.Hsapiens.dbSNP155.GRCh37 to run into this impossible dependency problem.

So I need to take back my claim that the BSgenome build failure that you reported had no impact whatsoever on the users or developers. It didn't cause the impossible dependency problem but it prolonged it by one days or two. That is the impact.

Ohhh, I see! That is a rather complex situation. Thank you so much for taking the time to explain all of this! Makes much more sense now.

BTW it doesn't help that the GHA log doesn't display more information about why installation of the 2 SNPlocs packages failed. This makes it almost impossible to understand the real reason why it failed.

Agreed! rworkflows currently uses the r-lib/setup-r-dependencies action to do this step, and unfortunately I don't see any options to increase verbosity. Perhaps I'll request this.

[bschilder]

Note that the R CMD check warnings about \item{} are due to a change in R devel and a fix for that has no business here (I'm actually considering a different fix but didn't have time to get to this yet).

Returned to the original state before my suggested fixes.

Also I'm not sure why this PR adds a .Rbuildignore

.Rbuildignore: This is actually necessary to avoid Notes about non-standard dirs like .github, where the rworkflows.yml workflow file is located. If you're ok with including this Note, I can remove it.

The other folders are for GHA, as these folders are automatically generated within the Windows VM and can cause errors during code checks. Though I did recently switch my R package dep installing step to using r-lib/setup-r-dependencies, so perhaps this is no longer necessary. I'll check on this. Update: These are indeed no longer necessary to add here, as the action takes care of it internally. I've remove these.

and a .gitignore file,

Whenever I work on a project I always make an Rproject file, which is quite useful for a lot of developer functions to reliably identify the main project directory (e.g. usethis, biocthis,devtools,here, rworkflows::use_workflow,). To avoid pushing this to GitHub after git add ., I added a .gitignore file indicating the following common R project files (.Rproj.user, .Ruserdata, etc.). Even if you yourself don't use any of these files, it can be helpful to include them in the .gitignore in anticipation of other contributors who may add them accidentally in the future.

Something to consider, but I'll remove this for you for now.

or adds https://github.com/Bioconductor/GenomicRanges

I usually prefer to have links to both Bio and the GitHub repo directly. But I've removed this link for you.

and RoxygenNote: 7.2.3 to the DESCRIPTION file. Please focus your PR on the rworkflows thing only.

I always run devtools::document before pushing to make sure all the docs match the code, and that any param documentation inherited from other packages is fully up to date. This automatically adds RoxygenNote: 7.2.3 to the DESCRIPTION. But I will also remove this, per your preference.

Update

I have now implemented all of these changes and pushed them to my fork.

[bschilder]

rworkflows is now passing on all OS except Linux, due to the \item syntax Warning previously discussed: https://github.com/neurogenomics/GenomicRanges/actions/runs/3854960940/jobs/6569504893#step:4:8724

[mtmorgan]

Been following this conversation because of a similar PR on Rsamtools. I was wondering if there were a way in github-action land to reduce code duplication across repositories, so you wouldn't have to update all packages that use rworkflows when the YAML file changes?

Also just to note, from last night, we can discover programmatically that the new BSgenome didn't propagate and the old one is still available...

> db = available.packages(repos = BiocManager::repositories()) |> as_tibble()
> db |> filter(Package == "BSgenome") |> select("Version")
# A tibble: 1 × 1
  Version
  <chr>
1 1.67.1

and simultaneously that the SNPlocs package has an impossible-to-satisfy dependency

> db |> filter(Package == "SNPlocs.Hsapiens.dbSNP155.GRCh37") |> select("Depends")
# A tibble: 1 × 1
  Depends
  <chr>
1 R (>= 4.2.0), BSgenome (>= 1.67.2)

This reiterates what Hervé says. It certainly wouldn't be a normal situation, though I know that the build system did (does?) push this sort of 'impossible' situation when a conscientious developer bumps the version requirement on reverse dependencies.

I was wondering whether having a more immediate CI like rworkflows would have changed this scenario, that Hervé would have been notified that BSgenome was going to fail, and could have updated it before it was built on the nightly builder? I guess the answer is 'maybe' depending on when the original commits were made, but at least on the margin it seems like a step forward.

[bschilder]

Thanks for the thoughtful insights @mtmorgan !

Been following this conversation because of a similar PR on Rsamtools. I was wondering if there were a way in github-action land to reduce code duplication across repositories, so you wouldn't have to update all packages that use rworkflows when the YAML file changes?

Actually, this is exactly what rworkflows aims to do! The vast majority of the GHA script is stored within the rworkflows action. This is centrally maintained for the very reason you stated, whenever a fix needs to be made every user doesn't have to edit/update their yaml files themselves. This is because the workflow script that you keep within your package's repository is just a very short script that calls the rworkflows action. The only thing that is intended for the users to edit are the parameters within the rworkflows action that I've chosen to expose to users, which are meant to be very easily editable (e.g. changing true --> false) without having to understand how to write yaml syntax.

What's more is, I'm only writing out the parameters to the short workflow here because it makes it easy for users to edit. e.g. here: https://github.com/neurogenomics/GenomicRanges/blob/master/.github/workflows/rworkflows.yml

But this would just as easily run if you didn't include any parameters at all, because I've tried to set sensible defaults that work out of the box (all described in the rworkflows action file).

To summarise, I've tried to make the repo-specific workflow files as minimal and simple as possible so that users never have to change it unless they want to change their parameters. All future versions of rworkflows will be carefully designed to be backcompatible with all previous versions of workflow scripts.

I was wondering whether having a more immediate CI like rworkflows would have changed this scenario, that Hervé would have been notified that BSgenome was going to fail, and could have updated it before it was built on the nightly builder? I guess the answer is 'maybe' depending on when the original commits were made, but at least on the margin it seems like a step forward.

Yeah, that's the hope. It becomes even more important for those who may not pay as close attention as both of you do to their code changes or the Bioc server messages. But I'm partly focusing on you guys bc of how influential you've been in the Bioc community, and if you begin these practices others who could benefit from it even more will hopefully follow. This is especially important for those who publish or release their R packages long before submitting to Bioc (sometimes years, or never!). In the course of writing the preprint, I found that:

"52% (25,713) of all R packages are exclusively distributed through GitHub"

rworkflows aims to make reproducible practices more immediately usable to everyone on the code platform that most people are already using (GitHub). But it may still be a helpful tool for expert developers like yourselves @mtmorgan @hpages. For example, I find it greatly reduces the time it takes for me to recognise and fix bugs on Linux and Windows, as I only own a Macbook.

[mtmorgan]

Actually, this is exactly what rworkflows aims to do!

Yep, I understand the motivation, it's just that the (guts of the) PR is 51 lines long (48 in Rsamtools!!), so I know from bitter experience that there are at least 50 opportunities for errors, and these will have to be changed in multiple locations (and already Rsamtools and GenomicRanges are out-of-sync in complicated ways...). The ideal PR will be one line...

[hpages]

@bschilder Don't get me wrong, suggested fixes are fine and welcome but they don't belong to this PR. They are distracting and slow down the process of discussing/merging the PR. This is true for PR's in general: they should really stick to the matter and not introduce additional random/unrelated changes.

Thanks for cleaning the PR.

rworkflows is now passing on all OS except Linux, due to the \item syntax Warning previously discussed:

Those are warnings, why is GHA returning an error?

Also please skip the run_bioccheck step. BiocCheck still tends to produce too many false positives for my taste. We've had some internal discussion about adding an option to run it with a reduced subset of consensual checks, but that didn't happen yet. Note that this is why we don't run it as part of our daily builds.

My main concern is about the installation mechanism of the deps. You said rworkflows uses r-lib/setup-r-dependencies which seems to be using pak::pkg_install(), but I'm not convinced that pak::pkg_install() knows how to grab packages from the correct BioC repos. For example, it will try to install BioC 3.16 packages in a BioC 3.15 installation:

> packageVersion("BiocVersion")
[1] ‘3.15.2’
> library(pak)
> pkg_install("BiocGenerics")

→ Will update 1 package.
→ Will download 1 package with unknown size.
+ BiocGenerics 0.42.0 → 0.44.0 [bld][dl]
? Do you want to continue (Y/n) 

Wrong! BiocGenerics 0.44.0 belongs to BioC 3.16. Installing it on top of a BioC 3.15 installation will mix up packages from different BioC versions which is very likely to cause package mix-up nightmare.

Sadly, all the package installation tools from the Rstudio ecosystem that I've checked so far (devtools, renv, Packrat) have failed to do the right thing. And it seems that pak keeps on with the tradition. Getting this right is tricky because BioC uses 6-month release cycles and R has annual releases. So each year there's a 6-month period where bioc release and devel both use R release. This is why we constantly remind people that the only true way to install Bioc packages is with BiocManager::install().

H.

[bschilder]

Hi @hpages , finally following up on this. We've made a number of improvements to the rworkflows actions.

rworkflows is now passing on all OS except Linux, due to the \item syntax Warning previously discussed:

Those are warnings, why is GHA returning an error?

Warnings cause checks (BiocCheckor rcmdcheck) to fail. Thus GHA shows an error.

Also please skip the run_bioccheck step. BiocCheck still tends to produce too many false positives for my taste. We've had some internal discussion about adding an option to run it with a reduced subset of consensual checks, but that didn't happen yet. Note that this is why we don't run it as part of our daily builds.

Sure, I've now set run_bioccheck to false.

My main concern is about the installation mechanism of the deps. You said rworkflows uses r-lib/setup-r-dependencies which seems to be using pak::pkg_install(), but I'm not convinced that pak::pkg_install() knows how to grab packages from the correct BioC repos. For example, it will try to install BioC 3.16 packages in a BioC 3.15 installation:

We addressed this by changing this step to use the bioc-actions/setup-bioc action instead, which I believe does a better job at coordinating R package versions using BiocManager. https://github.com/neurogenomics/rworkflows/blob/1f7118a3f22f9dc7c7c0b201a65e8e07ec960ce9/action.yml#L111 https://github.com/grimbough/bioc-actions/blob/v1-branch/setup-bioc/action.yml

 Next steps

Does this address all of your concerns? If so, last thing you'd need to do on your end would be to add the GitHub secret named PAT_GITHUB and merge the PR. See here for further instructions on setting up your token.

Just let me know if I missed anything and I'd happy to modify further.

Best, Brian

[bschilder]

Reopening after changes https://github.com/Bioconductor/GenomicRanges/pull/73#issuecomment-1700934926

[hpages]

Hi @bschilder,

Thanks for these changes.

Not sure about the introduction of this line:

>>>>>>> 7042d84877c1378bf6760cb08e497c6e9bc2b566

in the NEWS file, or about the introduction of an empty line in the DESCRIPTION file?

.Rbuildignore seems to be missing an EOL.

Also why add the entry:

    o Update .Rbuildignore

in the CHANGES IN VERSION 1.14.0 section far down in the NEWS file? GenomicRanges 1.14.0 was released 6 years ago, as part of BioC 2.6!

Best, H.

[bschilder]

Thanks for the quick reply, @hpages !

Not sure about the introduction of this line:

>>>>>>> 7042d84877c1378bf6760cb08e497c6e9bc2b566

in the NEWS file, or about the introduction of an empty line in the DESCRIPTION file?

.Rbuildignore seems to be missing an EOL.

Also why add the entry:

    o Update .Rbuildignore

in the CHANGES IN VERSION 1.14.0 section far down in the NEWS file? GenomicRanges 1.14.0 was released 6 years ago, as part of BioC 2.6!

These all seem to be merges gone slightly awry, perhaps along with some accidental pasting on my part. I've gone through and manually fixed each of them.

All you need to do on your end is add GH token as a GH secret named "PAT_GITHUB" to the main repo

I've actually obviated the need for you to do this step with some recent updates to rworkflows. By default, it uses the GITHUB_TOKEN variable that is automatically generated by GitHub. https://github.com/neurogenomics/rworkflows/pull/66

[bschilder]

@hpages is there anything else you need from me?

[hpages]

Hi @bschilder,

As @vjcitn mentioned here, adoption of rworkflows for core Bioconductor packages, as well as its official endorsement for Bioconductor packages in general, would still require a multiparty discussion that goes beyond this particular PR.

Personally, I still share the same concern as @mtmorgan about the workflow "doing the right thing", and continuing to do the right thing all year round, with respect to versioning. See Martin's comment here for the details.

Other than that this particular PR has the has_testthat and has_runit values wrong. They need to be the other way around (something you fixed in your PR for Rsamtools but not here).

Anyways, I would suggest that we keep the discussion about all this in the rworkflows PR for Rsamtools in order to avoid more dilution and repeated comments. Once a decision is made there, GenomicRanges will follow.

Thanks

[bschilder]

Other than that this particular PR has the has_testthat and has_runit values wrong. They need to be the other way around (something you fixed in your PR for Rsamtools but not here).

Sure, can fix that in 2 seconds! Note, you can always adjust the arguments to your liking anytime. The workflow file is designed to make this very easy.

Anyways, I would suggest that we keep the discussion about all this in the rworkflows PR for Rsamtools in order to avoid more dilution and repeated comments. Once a decision is made there, GenomicRanges will follow.

Will do!

[bschilder]

Other than that this particular PR has the has_testthat and has_runit values wrong. They need to be the other way around (something you fixed in your PR for Rsamtools but not here).

Sure, can fix that in 2 seconds! Note, you can always adjust the arguments to your liking anytime. The workflow file is designed to make this very easy.

Done

[hpages]

Note, you can always adjust the arguments to your liking anytime.

It's not about "adjusting arguments to my liking", it's about fixing a PR that is broken. There's a big difference :wink:

More generally speaking, I don't think it's fair to say "Here is a PR, it might work or not. Fix it if it doesn't, it should be easy". Especially after people took the time to review your PR and suggest corrections.

[bschilder]

@hpages I think I've addressed all issues you've raised. Do let me know if there's any others I may have missed.

[vjcitn]

@Brian Schilder @.***> thanks for this. We are still discussing our long term approach to GHA for core packages and for general bioc software management. The PR won't be merged until we have more internal discussion and policy development. I hope this is OK with you.

On Thu, Dec 28, 2023 at 1:20 PM Brian M. Schilder @.***> wrote:

@hpages https://github.com/hpages I think I've addressed all issues you've raised. Do let me know if there's any others I may have missed.

— Reply to this email directly, view it on GitHub https://github.com/Bioconductor/GenomicRanges/pull/73#issuecomment-1871396878, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDI5QVOMM2OQAMY5MTCFY3YLWZ7RAVCNFSM6AAAAAATEC62KGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRGM4TMOBXHA . You are receiving this because you were mentioned.Message ID: @.***>

-- The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance  HelpLine at http://www.partners.org/complianceline http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

[bschilder]

@brian Schilder @.***> thanks for this. We are still discussing our long term approach to GHA for core packages and for general bioc software management. The PR won't be merged until we have more internal discussion and policy development. I hope this is OK with you.

Thanks for the update @vjcitn ! No problem at all, just wanted to double check it was still on the docket. Let me know if there's anything I can to help in the meantime!

[hpages]

see https://github.com/Bioconductor/Rsamtools/pull/48#issuecomment-1871627155