On Fri, Oct 7, 2011 at 3:22 PM, Martin Morgan <mtmorgan@fhcrc.org> wrote:

> On 10/06/2011 10:04 AM, Cook, Malcolm wrote:
>
>> Hi Michael&  Martin,
>>
>> Michael replied to my problem (stated below) that:
>>
>> "This issue has been reported before. The resolution was that there
>> are odd things going on in the methods package. Pretty sure we
>> reported this to John."
>>
>> Ah, yes, now I see it has been reported, with Martin replying (on
>> 12/2010  in
>> https://stat.ethz.ch/**pipermail/bioconductor/2010-**December/036755.html<https://stat.ethz.ch/pipermail/bioconductor/2010-December/036755.html>
>> )
>>
>>  " I forwarded an example to John Chambers, and will report back
>> ..."  Pending a resolution, is there any advice for a best workaround
>> aside from not loading both `graph` and `rtracklayer` libraries.
>>
>> Also, off topic, but, is there any advice on tracking status of
>> issues with bioconductor packages other than emailing to the list and
>> package authors?  The CPAN (for perl) offers an 'rt bug tracker'
>> which forwards posted issues to developers.  Something like that
>> might be a grand addition!
>>
>
> Hi Malcolm -- tried to disentangle the bug tracker from the other parts of
> the post.
>
> There is no overall bug tracker; it is worth exploring, though no promises.
> Any feedback from other developers? I think my reservation is that only some
> would adopt the practice, meaning that the developer and the conscientious
> bug reporter interested in knowing whether an issued had been reported /
> resolved would have to look both on the list and in the tracker.
>
>
I guess I would argue that the mailing list is sufficient. At least on a
per-developer basis the number of "open" bug reports is relatively small and
the bugs tend to be easily fixed. This is probably due to the limited scope
and complexity of R packages (at least relative to say a large GUI
application). Any developer conscientious enough to use a bug tracker is
also conscientious enough to fix bugs relatively promptly. Another component
is that most Bioc packages are developed by single individuals, so
coordination is not so critical.

One caveat: it may be unclear to users whether the best practice for bug
reporting is sending an email to the mailing list or sending one to the
maintainer(s). Obviously, emailing only the maintainer should be
discouraged, because the report and resolution are not archived.

I found this:
http://bioconductor.org/packages/2.6/bioc/vignettes/Biobase/inst/doc/Bioconductor.pdf

Which does say in Prerequisites to submit bug reports to the mailing list,
but it is not clearly reiterated in the "How to report a bug" section.


Thanks for the suggestion! Martin
>
>
>> Thanks!
>>
>> ~Malcolm
>>
>> -----Original Message----- From: bioc-devel-bounces@r-project.**org<bioc-devel-bounces@r-project.org>
>> [mailto:bioc-devel-bounces@r-**project.org<bioc-devel-bounces@r-project.org>]
>> On Behalf Of Cook, Malcolm
>> Sent: Friday, June 10, 2011 2:57 PM To: 'Michael Lawrence' Cc:
>> 'bioc-devel@r-project.org'; 'bioc-sig-sequencing@r-**project.org<bioc-sig-sequencing@r-project.org>
>> '
>> Subject: [Bioc-devel] graph package conflict with rtracklayer
>>
>> Michael&  Robert,
>>
>> If I load the graph package prior to rtracklayer, import.bed
>> generates an error and fails.  It otherwise succeeds if I don't load
>> the graph package.
>>
>> It happens both with rtracklayer from svn and production.
>>
>> Look:
>>
>> In a fresh session:
>>
>>  library(graph) library(rtracklayer)
>>>
>> Loading required package: RCurl Loading required package: bitops
>>
>>> b<- import.bed('my.bed')
>>>
>> Error in function (classes, fdef, mtable)  : unable to find an
>> inherited method for function "import.ucsc", for signature "file"
>>
>>> sessionInfo()
>>>
>> R version 2.13.0 (2011-04-13) Platform:
>> x86_64-apple-darwin9.8.0/x86_**64 (64-bit)
>>
>> locale: [1] C
>>
>> attached base packages: [1] stats     graphics  grDevices utils
>> datasets  methods   base
>>
>> other attached packages: [1] rtracklayer_1.13.3 RCurl_1.5-0
>> bitops_1.0-4.1     graph_1.30.0
>>
>> loaded via a namespace (and not attached): [1] BSgenome_1.20.0
>> Biostrings_2.20.1   GenomicRanges_1.4.6 [4] IRanges_1.10.4
>> XML_3.4-0           tools_2.13.0
>>
>>>
>>>
>> ______________________________**_________________
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/**listinfo/bioc-devel<https://stat.ethz.ch/mailman/listinfo/bioc-devel>
>>
>
>
> --
> Computational Biology
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
>
> Location: M1-B861
> Telephone: 206 667-2793
>
> ______________________________**_________________
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/**listinfo/bioc-devel<https://stat.ethz.ch/mailman/listinfo/bioc-devel>
>

	[[alternative HTML version deleted]]

