dear maintainers, I am currently listed as maintainer of Bioconductor package MoonlightR, designed for the prediction of cancer driver genes, which implements the Moonlight workflow. We are currently working on a second version of our workflow, called Moonlight2, and would like to have it released on Bioconductor as well, in form of the Moonlight2R package. The new package uses similar principles as the current one, but will have significant changes and updates, both in terms of new functionality and revision of old functionalities. The Moonlight2R project/paper will also have in part a different corresponding authorship respect to the current one. MoonlightR and Moonlight2R currently reside in two separate GitHub repositories. Ideally we would like to have both packages on BioConductor for the moment, the old one (called MoonlightR) and the new one that we intend to submit before the April cut-off for 3.17 (called Moonlight2R), where the number signifies the version of the protocol rather than the software. However on the package submission list, I see that having package names that "imply a temporal relationship" respect to an existing package is discouraged. Given the circumstances, do you think it would be possible to use the Moonlight2R name for the package (i.e. would it be a reason for rejection or object of revision during submission) or is it fair to keep it as is? Many thanks Matteo Tiberti Danish Cancer Society Research Center Strandboulevarden 49 DK-2100 Copenhagen Telephone: +45 35 25 73 07 [https://i.xink.io/Images/Get/K116/d1.png]<https://www.cancer.dk/?utm_source=email&utm_medium=medarbejderemail&utm_campaign=medarbejderemail&utm_content=cancerdk> www.cancer.dk<https://www.cancer.dk/international/> | Vores privatlivspolitik<https://www.cancer.dk/om-os/privatlivspolitik/>
[Bioc-devel] name for new BioC package
7 messages · Laurent Gatto, Hervé Pagès, Kevin Coombes +3 more
Dear Matteo, Not a direct answer to your question, but here's another angle to it, from a software development perspective. Once Moonlight2R will be available, would you consider MoonlightR to still be a viable alternative? If not, then you should also plan the deprecation of MoonlightR. In that case, the new code base could be added to MoonlightR (with a major version bump) and you could add a deprecation warning to the old code (see ?deprecated) that would become defunct (and removed) 6 month later. As for authors, all can be added to the DESCRIPTION file, with details about respective contributions in the manual pages. Best wishes, Laurent
From: Bioc-devel <bioc-devel-bounces at r-project.org> on behalf of Matteo Tiberti <tiberti at cancer.dk>
Sent: 03 February 2023 09:08
To: bioc-devel at r-project.org
Subject: [Bioc-devel] name for new BioC package
Sent: 03 February 2023 09:08
To: bioc-devel at r-project.org
Subject: [Bioc-devel] name for new BioC package
dear maintainers, I am currently listed as maintainer of Bioconductor package MoonlightR, designed for the prediction of cancer driver genes, which implements the Moonlight workflow. We are currently working on a second version of our workflow, called Moonlight2, and would like to have it released on Bioconductor as well, in form of the Moonlight2R package. The new package uses similar principles as the current one, but will have significant changes and updates, both in terms of new functionality and revision of old functionalities. The Moonlight2R project/paper will also have in part a different corresponding authorship respect to the current one. MoonlightR and Moonlight2R currently reside in two separate GitHub repositories. Ideally we would like to have both packages on BioConductor for the moment, the old one (called MoonlightR) and the new one that we intend to submit before the April cut-off for 3.17 (called Moonlight2R), where the number signifies the version of the protocol rather than the software. However on the package submission list, I see that having package names that "imply a temporal relationship" respect to an existing package is discouraged. Given the circumstances, do you think it would be possible to use the Moonlight2R name for the package (i.e. would it be a reason for rejection or object of revision during submission) or is it fair to keep it as is? Many thanks Matteo Tiberti Danish Cancer Society Research Center Strandboulevarden 49 DK-2100 Copenhagen Telephone: +45 35 25 73 07 [https://i.xink.io/Images/Get/K116/d1.png]<https://www.cancer.dk/?utm_source=email&utm_medium=medarbejderemail&utm_campaign=medarbejderemail&utm_content=cancerdk> www.cancer.dk<https://www.cancer.dk/international/> | Vores privatlivspolitik<https://www.cancer.dk/om-os/privatlivspolitik/> [[alternative HTML version deleted]] _______________________________________________ Bioc-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Hi Matteo. We had DESeq2 after DESeq, Rbowtie2 after Rbowtie, MOFA2 after MOFA, etc.. so I don't see any problem, but thanks for asking! Best, H.
On 03/02/2023 00:08, Matteo Tiberti wrote:
dear maintainers, I am currently listed as maintainer of Bioconductor package MoonlightR, designed for the prediction of cancer driver genes, which implements the Moonlight workflow. We are currently working on a second version of our workflow, called Moonlight2, and would like to have it released on Bioconductor as well, in form of the Moonlight2R package. The new package uses similar principles as the current one, but will have significant changes and updates, both in terms of new functionality and revision of old functionalities. The Moonlight2R project/paper will also have in part a different corresponding authorship respect to the current one. MoonlightR and Moonlight2R currently reside in two separate GitHub repositories. Ideally we would like to have both packages on BioConductor for the moment, the old one (called MoonlightR) and the new one that we intend to submit before the April cut-off for 3.17 (called Moonlight2R), where the number signifies the version of the protocol rather than the software. However on the package submission list, I see that having package names that "imply a temporal relationship" respect to an existing package is discouraged. Given the circumstances, do you think it would be possible to use the Moonlight2R name for the package (i.e. would it be a reason for rejection or object of revision during submission) or is it fair to keep it as is? Many thanks Matteo Tiberti Danish Cancer Society Research Center Strandboulevarden 49 DK-2100 Copenhagen Telephone: +45 35 25 73 07 [https://i.xink.io/Images/Get/K116/d1.png]<https://www.cancer.dk/?utm_source=email&utm_medium=medarbejderemail&utm_campaign=medarbejderemail&utm_content=cancerdk> www.cancer.dk<https://www.cancer.dk/international/> | Vores privatlivspolitik<https://www.cancer.dk/om-os/privatlivspolitik/> [[alternative HTML version deleted]]
_______________________________________________ Bioc-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Herv? Pag?s Bioconductor Core Team hpages.on.github at gmail.com
For the record, as a user, I *hated* the move from MOFA to MOFA2. Not the new package name, but the fact that they also Schanged all the function names and argument names. Mostly, they switched from using periods to underscores. But this meant having to tediously hand-edit every script that used MOFA in order to continue using that script in newer versions of R (since they also discontinued supporting the MOFA package in newer versions). Also, some of the changes produced less useful graphical summaries, to the extent that I took the time to write my own code to reproduce the original versions. So, I would suggest that you at least think about how much work you are creating for your established users before making the change. And make choices that minimize the burden you are imposing on them. Best, Kevin
On Sat, Feb 4, 2023, 1:03 AM Herv? Pag?s <hpages.on.github at gmail.com> wrote:
Hi Matteo. We had DESeq2 after DESeq, Rbowtie2 after Rbowtie, MOFA2 after MOFA, etc.. so I don't see any problem, but thanks for asking! Best, H. On 03/02/2023 00:08, Matteo Tiberti wrote:
dear maintainers, I am currently listed as maintainer of Bioconductor package MoonlightR,
designed for the prediction of cancer driver genes, which implements the Moonlight workflow.
We are currently working on a second version of our workflow, called
Moonlight2, and would like to have it released on Bioconductor as well, in form of the Moonlight2R package. The new package uses similar principles as the current one, but will have significant changes and updates, both in terms of new functionality and revision of old functionalities. The Moonlight2R project/paper will also have in part a different corresponding authorship respect to the current one. MoonlightR and Moonlight2R currently reside in two separate GitHub repositories.
Ideally we would like to have both packages on BioConductor for the
moment, the old one (called MoonlightR) and the new one that we intend to submit before the April cut-off for 3.17 (called Moonlight2R), where the number signifies the version of the protocol rather than the software. However on the package submission list, I see that having package names that "imply a temporal relationship" respect to an existing package is discouraged. Given the circumstances, do you think it would be possible to use the Moonlight2R name for the package (i.e. would it be a reason for rejection or object of revision during submission) or is it fair to keep it as is?
Many thanks Matteo Tiberti Danish Cancer Society Research Center Strandboulevarden 49 DK-2100 Copenhagen Telephone: +45 35 25 73 07 [https://i.xink.io/Images/Get/K116/d1.png]<
https://www.cancer.dk/?utm_source=email&utm_medium=medarbejderemail&utm_campaign=medarbejderemail&utm_content=cancerdk
www.cancer.dk<https://www.cancer.dk/international/> | Vores
privatlivspolitik<https://www.cancer.dk/om-os/privatlivspolitik/>
[[alternative HTML version deleted]]
_______________________________________________ Bioc-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
-- Herv? Pag?s Bioconductor Core Team hpages.on.github at gmail.com
_______________________________________________ Bioc-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
2 days later
Dear all, thanks for your input just to answer on your different points: @Kevin Coombes<mailto:kevin.r.coombes at gmail.com> I agree it can be annoying - we don't intend to heavily change the API, we mostly want to add functionality and refactoring some of the internals (including basic information that the package uses), which means results of Moonlight2R will be significantly different from MoonlightR @Laurent, I think we will eventually deprecate MoonlightR but we would prefer having both of them on Bioconductor for now, as e.g. it makes it easier to run comparisons which are reproducible without too much pain @Herv? Pag?s<mailto:hpages.on.github at gmail.com> thanks a lot! I think we will keep the name with 2 for now Best regards, Matteo Tiberti Danish Cancer Society Strandboulevarden 49 DK-2100 Copenhagen Telefon: +45 35 25 73 07 [cid:14bd0b1b-c32e-460e-bd97-b434f126f8c5]<https://www.cancer.dk/?utm_source=email&utm_medium=medarbejderemail&utm_campaign=medarbejderemail&utm_content=cancerdk> www.cancer.dk<https://www.cancer.dk/international/> | Vores privatlivspolitik<https://www.cancer.dk/om-os/privatlivspolitik/>
From: Kevin Coombes <kevin.r.coombes at gmail.com>
Sent: 04 February 2023 14:26
To: Herv? Pag?s <hpages.on.github at gmail.com>
Cc: Matteo Tiberti <tiberti at cancer.dk>; bioc-devel at r-project.org <bioc-devel at r-project.org>
Subject: Re: [Bioc-devel] name for new BioC package
Sent: 04 February 2023 14:26
To: Herv? Pag?s <hpages.on.github at gmail.com>
Cc: Matteo Tiberti <tiberti at cancer.dk>; bioc-devel at r-project.org <bioc-devel at r-project.org>
Subject: Re: [Bioc-devel] name for new BioC package
For the record, as a user, I *hated* the move from MOFA to MOFA2. Not the new package name, but the fact that they also Schanged all the function names and argument names. Mostly, they switched from using periods to underscores. But this meant having to tediously hand-edit every script that used MOFA in order to continue using that script in newer versions of R (since they also discontinued supporting the MOFA package in newer versions). Also, some of the changes produced less useful graphical summaries, to the extent that I took the time to write my own code to reproduce the original versions. So, I would suggest that you at least think about how much work you are creating for your established users before making the change. And make choices that minimize the burden you are imposing on them. Best, Kevin On Sat, Feb 4, 2023, 1:03 AM Herv? Pag?s <hpages.on.github at gmail.com<mailto:hpages.on.github at gmail.com>> wrote: Hi Matteo. We had DESeq2 after DESeq, Rbowtie2 after Rbowtie, MOFA2 after MOFA, etc.. so I don't see any problem, but thanks for asking! Best, H. On 03/02/2023 00:08, Matteo Tiberti wrote: > dear maintainers, > > I am currently listed as maintainer of Bioconductor package MoonlightR, designed for the prediction of cancer driver genes, which implements the Moonlight workflow. > > We are currently working on a second version of our workflow, called Moonlight2, and would like to have it released on Bioconductor as well, in form of the Moonlight2R package. The new package uses similar principles as the current one, but will have significant changes and updates, both in terms of new functionality and revision of old functionalities. The Moonlight2R project/paper will also have in part a different corresponding authorship respect to the current one. MoonlightR and Moonlight2R currently reside in two separate GitHub repositories. > > Ideally we would like to have both packages on BioConductor for the moment, the old one (called MoonlightR) and the new one that we intend to submit before the April cut-off for 3.17 (called Moonlight2R), where the number signifies the version of the protocol rather than the software. However on the package submission list, I see that having package names that "imply a temporal relationship" respect to an existing package is discouraged. Given the circumstances, do you think it would be possible to use the Moonlight2R name for the package (i.e. would it be a reason for rejection or object of revision during submission) or is it fair to keep it as is? > > Many thanks > > Matteo Tiberti > > Danish Cancer Society Research Center > Strandboulevarden 49 > DK-2100 Copenhagen > Telephone: +45 35 25 73 07 > > > [https://i.xink.io/Images/Get/K116/d1.png<https://i.xink.io/Images/Get/K116/d1.png>]<https://www.cancer.dk/?utm_source=email&utm_medium=medarbejderemail&utm_campaign=medarbejderemail&utm_content=cancerdk> > > www.cancer.dk<http://www.cancer.dk><https://www.cancer.dk/international/> | Vores privatlivspolitik<https://www.cancer.dk/om-os/privatlivspolitik/> > > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel at r-project.org<mailto:Bioc-devel at r-project.org> mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel<https://stat.ethz.ch/mailman/listinfo/bioc-devel> -- Herv? Pag?s Bioconductor Core Team hpages.on.github at gmail.com<mailto:hpages.on.github at gmail.com> _______________________________________________ Bioc-devel at r-project.org<mailto:Bioc-devel at r-project.org> mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel<https://stat.ethz.ch/mailman/listinfo/bioc-devel>
If you choose to introduce a second package, I would suggest immediately deprecating MoonlightR. The two versions co-exist for a development and release cycle for comparison / opportunity for users to adjust, and then there is only MoonlightR2. This avoids confusion for new users. You can focus development & support efforts on the new version. Users wishing to compare results can use the version of R / Bioconductor where both packages were available. Users wishing to rigorously reproduce previous results are in the unenviable position of re-creating an R environment from the original analysis; they do not benefit from having MoonlightR available in the current (i.e., different) R / Bioconductor. The transition from DESeq to DESeq2 was very protracted, and ?at the end? there were still new users starting with the very outdated DESeq, and still requests to support DESeq that were no longer relevant. Martin From: Bioc-devel <bioc-devel-bounces at r-project.org> on behalf of Matteo Tiberti <tiberti at cancer.dk> Date: Tuesday, February 7, 2023 at 6:54 AM To: Kevin Coombes <kevin.r.coombes at gmail.com>, Herv? Pag?s <hpages.on.github at gmail.com> Cc: bioc-devel at r-project.org <bioc-devel at r-project.org> Subject: Re: [Bioc-devel] name for new BioC package Dear all, thanks for your input just to answer on your different points: @Kevin Coombes<mailto:kevin.r.coombes at gmail.com> I agree it can be annoying - we don't intend to heavily change the API, we mostly want to add functionality and refactoring some of the internals (including basic information that the package uses), which means results of Moonlight2R will be significantly different from MoonlightR @Laurent, I think we will eventually deprecate MoonlightR but we would prefer having both of them on Bioconductor for now, as e.g. it makes it easier to run comparisons which are reproducible without too much pain @Herv? Pag?s<mailto:hpages.on.github at gmail.com> thanks a lot! I think we will keep the name with 2 for now Best regards, Matteo Tiberti Danish Cancer Society Strandboulevarden 49 DK-2100 Copenhagen Telefon: +45 35 25 73 07 [cid:14bd0b1b-c32e-460e-bd97-b434f126f8c5]<https://www.cancer.dk/?utm_source=email&utm_medium=medarbejderemail&utm_campaign=medarbejderemail&utm_content=cancerdk> www.cancer.dk<https://www.cancer.dk/international/> | Vores privatlivspolitik<https://www.cancer.dk/om-os/privatlivspolitik/>
From: Kevin Coombes <kevin.r.coombes at gmail.com>
Sent: 04 February 2023 14:26
To: Herv? Pag?s <hpages.on.github at gmail.com>
Cc: Matteo Tiberti <tiberti at cancer.dk>; bioc-devel at r-project.org <bioc-devel at r-project.org>
Subject: Re: [Bioc-devel] name for new BioC package
Sent: 04 February 2023 14:26
To: Herv? Pag?s <hpages.on.github at gmail.com>
Cc: Matteo Tiberti <tiberti at cancer.dk>; bioc-devel at r-project.org <bioc-devel at r-project.org>
Subject: Re: [Bioc-devel] name for new BioC package
For the record, as a user, I *hated* the move from MOFA to MOFA2. Not the new package name, but the fact that they also Schanged all the function names and argument names. Mostly, they switched from using periods to underscores. But this meant having to tediously hand-edit every script that used MOFA in order to continue using that script in newer versions of R (since they also discontinued supporting the MOFA package in newer versions). Also, some of the changes produced less useful graphical summaries, to the extent that I took the time to write my own code to reproduce the original versions. So, I would suggest that you at least think about how much work you are creating for your established users before making the change. And make choices that minimize the burden you are imposing on them. Best, Kevin On Sat, Feb 4, 2023, 1:03 AM Herv? Pag?s <hpages.on.github at gmail.com<mailto:hpages.on.github at gmail.com>> wrote: Hi Matteo. We had DESeq2 after DESeq, Rbowtie2 after Rbowtie, MOFA2 after MOFA, etc.. so I don't see any problem, but thanks for asking! Best, H. On 03/02/2023 00:08, Matteo Tiberti wrote: > dear maintainers, > > I am currently listed as maintainer of Bioconductor package MoonlightR, designed for the prediction of cancer driver genes, which implements the Moonlight workflow. > > We are currently working on a second version of our workflow, called Moonlight2, and would like to have it released on Bioconductor as well, in form of the Moonlight2R package. The new package uses similar principles as the current one, but will have significant changes and updates, both in terms of new functionality and revision of old functionalities. The Moonlight2R project/paper will also have in part a different corresponding authorship respect to the current one. MoonlightR and Moonlight2R currently reside in two separate GitHub repositories. > > Ideally we would like to have both packages on BioConductor for the moment, the old one (called MoonlightR) and the new one that we intend to submit before the April cut-off for 3.17 (called Moonlight2R), where the number signifies the version of the protocol rather than the software. However on the package submission list, I see that having package names that "imply a temporal relationship" respect to an existing package is discouraged. Given the circumstances, do you think it would be possible to use the Moonlight2R name for the package (i.e. would it be a reason for rejection or object of revision during submission) or is it fair to keep it as is? > > Many thanks > > Matteo Tiberti > > Danish Cancer Society Research Center > Strandboulevarden 49 > DK-2100 Copenhagen > Telephone: +45 35 25 73 07 > > > [https://i.xink.io/Images/Get/K116/d1.png<https://i.xink.io/Images/Get/K116/d1.png>]<https://www.cancer.dk/?utm_source=email&utm_medium=medarbejderemail&utm_campaign=medarbejderemail&utm_content=cancerdk<https://i.xink.io/Images/Get/K116/d1.png%3chttps:/i.xink.io/Images/Get/K116/d1.png%3e%5d%3chttps:/www.cancer.dk/?utm_source=email&utm_medium=medarbejderemail&utm_campaign=medarbejderemail&utm_content=cancerdk>> > > www.cancer.dk<http://www.cancer.dk><https://www.cancer.dk/international/<http://www.cancer.dk%3e%3chttps:/www.cancer.dk/international/>> | Vores privatlivspolitik<https://www.cancer.dk/om-os/privatlivspolitik/> > > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel at r-project.org<mailto:Bioc-devel at r-project.org> mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel<https://stat.ethz.ch/mailman/listinfo/bioc-devel><https://stat.ethz.ch/mailman/listinfo/bioc-devel%3chttps:/stat.ethz.ch/mailman/listinfo/bioc-devel%3e> -- Herv? Pag?s Bioconductor Core Team hpages.on.github at gmail.com<mailto:hpages.on.github at gmail.com> _______________________________________________ Bioc-devel at r-project.org<mailto:Bioc-devel at r-project.org> mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel<https://stat.ethz.ch/mailman/listinfo/bioc-devel><https://stat.ethz.ch/mailman/listinfo/bioc-devel%3chttps:/stat.ethz.ch/mailman/listinfo/bioc-devel%3e> _______________________________________________ Bioc-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
2 days later
Hi Kevin & all I guess there are two basic scenarios: - PKG2 is a plug-in replacement for PKG. In this case the API should change as little as possible. PKG should be deprecated. One can even argue whether the name change is necessary. (It may be opportune for reasons of credit / assignment of responsibility.) - PKG2 is a fundamentally better approach than PKG, and a new API is appropriate. In this case, it?s fair to still keep PKG around, for all the people who like and use it, and let them decide at their own pace if and when they migrate. We did this e.g. with DESeq/DESeq2, which co-existed for several years. Thanks for the feedback on MOFA/MOFA2. I was a co-author of MOFA but not MOFA2, and it seems we did not follow the above advice. Sorry. Thanks and best wishes Wolfgang -- Wolfgang Huber EMBL https://www.embl.org/groups/huber
Il giorno 04.02.2023, alle ore 14:26, Kevin Coombes <kevin.r.coombes at gmail.com> ha scritto: For the record, as a user, I *hated* the move from MOFA to MOFA2. Not the new package name, but the fact that they also Schanged all the function names and argument names. Mostly, they switched from using periods to underscores. But this meant having to tediously hand-edit every script that used MOFA in order to continue using that script in newer versions of R (since they also discontinued supporting the MOFA package in newer versions). Also, some of the changes produced less useful graphical summaries, to the extent that I took the time to write my own code to reproduce the original versions. So, I would suggest that you at least think about how much work you are creating for your established users before making the change. And make choices that minimize the burden you are imposing on them. Best, Kevin On Sat, Feb 4, 2023, 1:03 AM Herv? Pag?s <hpages.on.github at gmail.com> wrote:
Hi Matteo. We had DESeq2 after DESeq, Rbowtie2 after Rbowtie, MOFA2 after MOFA, etc.. so I don't see any problem, but thanks for asking! Best, H. On 03/02/2023 00:08, Matteo Tiberti wrote:
dear maintainers, I am currently listed as maintainer of Bioconductor package MoonlightR,
designed for the prediction of cancer driver genes, which implements the Moonlight workflow.
We are currently working on a second version of our workflow, called
Moonlight2, and would like to have it released on Bioconductor as well, in form of the Moonlight2R package. The new package uses similar principles as the current one, but will have significant changes and updates, both in terms of new functionality and revision of old functionalities. The Moonlight2R project/paper will also have in part a different corresponding authorship respect to the current one. MoonlightR and Moonlight2R currently reside in two separate GitHub repositories.
Ideally we would like to have both packages on BioConductor for the
moment, the old one (called MoonlightR) and the new one that we intend to submit before the April cut-off for 3.17 (called Moonlight2R), where the number signifies the version of the protocol rather than the software. However on the package submission list, I see that having package names that "imply a temporal relationship" respect to an existing package is discouraged. Given the circumstances, do you think it would be possible to use the Moonlight2R name for the package (i.e. would it be a reason for rejection or object of revision during submission) or is it fair to keep it as is?
Many thanks Matteo Tiberti Danish Cancer Society Research Center Strandboulevarden 49 DK-2100 Copenhagen Telephone: +45 35 25 73 07 [https://i.xink.io/Images/Get/K116/d1.png]<
https://www.cancer.dk/?utm_source=email&utm_medium=medarbejderemail&utm_campaign=medarbejderemail&utm_content=cancerdk
www.cancer.dk<https://www.cancer.dk/international/> | Vores
privatlivspolitik<https://www.cancer.dk/om-os/privatlivspolitik/>
[[alternative HTML version deleted]]
_______________________________________________ Bioc-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
-- Herv? Pag?s Bioconductor Core Team hpages.on.github at gmail.com
_______________________________________________ Bioc-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[[alternative HTML version deleted]]
_______________________________________________ Bioc-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel