Re: [Bioc-devel] readGAlignments Lacks strandMode

[Dario Strbenac]

Good day,

Now I know about invertStrand, I agree that it's best to keep the strandMode 
only for paired-end data. Indeed, it's an example at the end of the lengthy 
documentation of GAlignments.

--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Code quality and bug reports

[Lluís Revilla]

Dear Valerie and all,

If I understood the page you kindly linked correctly, a package is deprecated:
1) When it fails to build and check (unless it is fixed).
2) When the maintainer asks for it.
3) If the maintainer is unresponsive (I assume when a mail is not
delivered) and(/or?) doesn't answers questions about the package (How
is this tracked? Which is the threshold for unanswered questions, 1
year? )

In some packages, it seems the maintainers receive the mails, and the
packages build and past the daily checks of Bioconductor, but there
are bugs and issues with those packages that are left unanswered and
unsolved in support.bioconductor.org. Those packages that are still
functional and used but don't receive maintenance are then kept ? How
should the community help to solve those issues?

Thanks,

Lluís

On 6 January 2017 at 18:56, Obenchain, Valerie
 wrote:
> On 01/04/2017 07:53 AM, Lluís Revilla wrote:
>> Dear Guangchuang and all,
>>
>> Quality of the packages has been a preoccupation of the project from
>> the  beginning  (see
>> https://stat.ethz.ch/pipermail/bioc-devel/2014-May/005810.html for
>> more references and other discussions about bug reports.) Despite not
>> being in a goal of the project, it is necessary to do a reproducible
>> research, which it is a goal: "To further scientific understanding by
>> producing high-quality documentation and reproducible research.".
>> Although it seems that this discussion appears periodically
>> Bioconductor I don't know any solution in the project.
>>
>> I have never submitted a package to Bioconductor or CRAN, and I am
>> quite new to R (and is my first mail to the list), but one thing that
>> I keep thinking (before publishing a package) is the maintainability
>> of it. I don't know how much time/desires will I have to dedicate to a
>> package (if it is accepted) in the future, but at the same time I want
>> to make useful code to be used in further research beyond my own
>> project.
>>
>> However the Bioconductor core team may be already too busy to deal
>> with the issues of all packages. Maybe it would be better to bring
>> CRAN's policy to orphan packages (see:
>> https://cran.r-project.org/src/contrib/Orphaned/README):
>
> Bioconductor does have a system for dealing with orphaned packages
> called End of Life:
>
>   http://www.bioconductor.org/developers/package-end-of-life/
>
> Deprecated packages have a strikethrough the name on the build reports,
> e.g., the saps package,
>
>   http://www.bioconductor.org/checkResults/devel/bioc-LATEST/
>
>
> Valerie
>
>>
>> "Possible reasons for orphanizing a package:
>>
>> 1) The current maintainer actively wants to orphanize the package,
>>e.g., due to no longer having time or interest to act as package
>>maintainer.
>>
>> 2) Emails sent to the current maintainer by the CRAN admins bounced, or
>>were not answered for longer periods of time.
>> "
>> Example of an orhpan package is clusterRepro.
>>
>> To orphanize a package the current maintainer could post it here on
>> the devel list and ask for a maintainer on the support site, and it is
>> his/her decision to whom is passed the responsibility.
>> Otherwise, maybe the limit of time without answering mails/posts in
>> support could be 3 months/6 months. (I don't know the CRAN decision
>> when not answering mails)
>>
>> Once the orphaned status is reached maybe however who wants could send
>> patches or take the maintenance of the package for another 3 months or
>> more.
>>
>> This status would not make bugs easier to fix or control, but could
>> mark that a package is not in the best maintenance status.
>>
>> Hope this helps,
>>
>> Lluís
>>
>>
>> 
>> Date: Wed, 4 Jan 2017 15:38:53 +0800
>> From: "Yu, Guangchuang" 
>> To: bioc-devel 
>> Subject: [Bioc-devel] report package issue to Bioconductor
>> Message-ID:
>> 
>> Content-Type: text/plain; charset="UTF-8"
>>
>> Dear all,
>>
>> Some packages never updated after they publish a paper, and they just
>> ignore bug report.
>>
>> I think we need somewhere, maybe on github, to post code review and
>> Bioconductor core team can take action if maintainer fail to fix issue.
>>
>> Here is a quick look of the CorMut package:
>> https://gist.github.com/GuangchuangYu/91b3396c7e49ab42c565a9cda3c35e18.
>>
>> There should be more issues than I can found with quick look of the source
>> code.
>>
>> Best wishes,
>> Guangchuang
>> ?
>> --
>> --~--~-~--~~~---~--~~
>> Guangchuang Yu, PhD Candidate
>> State Key Laboratory of Emerging Infectious Diseases
>> School of Public Health
>> The University of Hong Kong
>> Hong Kong SAR, China
>> www: https://guangchuangyu.github.io
>> -~--~~~~--~~--~--~---
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> 

Re: [Bioc-devel] Dependency on devtools in biocLite()

[Martin Morgan]

On 01/13/2017 06:29 PM, Andrzej Oleś wrote:

Dear all,

it's great that for some time now `biocLite()` also resolves package
dependencies for GitHub hosted packages. However, as this functionality
depends on devtools, an attempt to install a GitHub package when devtools
is not installed results in an error


library(BiocInstaller)
biocLite("aoles/RBioFormats")

BioC_mirror: https://bioconductor.org
Using Bioconductor 3.4 (BiocInstaller 1.24.0), R 3.3.2 (2016-10-31).
Error: package 'devtools' not available: there is no package called
‘devtools’

If this is the case, one would typically need to first install devtools,
and rerun the biocLite command. I was wondering whether it would make sense
to modify the behavior such that before attempting to call
`devtools::install` in

https://github.com/Bioconductor-mirror/BiocInstaller/blob/
9965cc72d009bfcae6776a02e5abb94cbd5dd109/R/biocLite.R#L48

first check for devtools availability and try to automatically install it
if missing (maybe by prompting the user). What do you think?


I'm not a fan of automatic package installation, e.g., because a user 
(e.g., me) might have a configuration of library paths that they are 
trying to maintain. This leads me down the slippery slope of not wanting 
to offer to install a package, either, because again the offer would be 
too narrow, some users (again, e.g., me) will reject it and prefer to 
have control, and so why not have a standard work flow -- user fixes 
package installation to their satisfaction and tries again -- rather 
than a conditional work flow.


On the other hand the error message "package 'devtools' not available: 
there is no package called 'devtools'" seems to be poorly worded -- 
there is a package devtools, and it is available, just not in the 
current installation. One could try to provide a better message, but one 
would rather the message were improved upstream so all similar 
situations were handled the same; at least this way the user has to 
learn only once what the message means.


Martin



Cheers,
Andrzej

[[alternative HTML version deleted]]

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




This email message may contain legally privileged and/or...{{dropped:2}}

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