Thanks, Sean. Yes, it's all there at the low level, but unless we expect
the user to interact only with the command-line, we need a GUI, and we
should probably just defer to github on that. Pre-population of the issue
with sessionInfo, possibly the last error message/traceback, would be a
reasonabl
On Fri, May 23, 2014 at 4:34 PM, Michael Lawrence
wrote:
> I like the idea about extracting important environmental information.
> Possibly the function that browses to the bug tracker could print out the
> sessionInfo for copy/paste.
>
> It is tempting to push the automation further, e.g. talking
I like the idea about extracting important environmental information.
Possibly the function that browses to the bug tracker could print out the
sessionInfo for copy/paste.
It is tempting to push the automation further, e.g. talking to github via a
web API to pre-populate, but it's a slippery slope
urls, browsers ... :(
how about a variation on utils:: bug.report in biobase? each package could
have a bugReportHandle method that is called when reportBug is called with
the package name as argument. the biobase version would gather key
environmental information at the time of the call and cou
The CRAN page for a package also includes the BugReports field
(besides the URL field), and I believe that is certainly a better link
for bug reporting purposes.
Regards,
Yihui
--
Yihui Xie
Web: http://yihui.name
On Fri, May 23, 2014 at 2:58 PM, Dan Tenenbaum wrote:
>
>
> - Original Messag
Yea, but I was thinking a formal field for the bug tracker (like
IssueTracker), for the sake of clarity. The package page could somehow
highlight it to keep people from missing it. And maybe even an automated
way from within R to browse to the tracker URL.
On Fri, May 23, 2014 at 12:58 PM, Dan T
- Original Message -
> From: "Michael Lawrence"
> To: "Kasper Daniel Hansen"
> Cc: "Michael Lawrence" , bioc-devel@r-project.org
> Sent: Friday, May 23, 2014 12:48:55 PM
> Subject: Re: [Bioc-devel] Bug tracker for Bioconductor?
>
> To support the decentralized model, it would be nice t
To support the decentralized model, it would be nice to have a standard way
of directing users to the right bug tracker. Perhaps this could be
specified as a URL in the DESCRIPTION and the Bioc package page could link
to it.
On Fri, May 23, 2014 at 12:42 PM, Kasper Daniel Hansen <
kasperdanielhan
I want to remind some posters in this thread that most Bioconductor
packages are being developed by non-overlapping sets of people and that it
is therefore not clear at all that a common bug tracker across the project
is necessary (says the person who has definitely "lost" bugs reported per
email).
Hi Ilari,
- Original Message -
> From: "Ilari Scheinin"
> To: bioc-devel@r-project.org
> Sent: Friday, May 23, 2014 12:24:23 PM
> Subject: Re: [Bioc-devel] Bioconductor git-svn bridge is available
>
> I’m also having issues with my bridges. It seems that they always
> “die" after the ini
Michael,
Well, BioC has many suggestions and requirements for how packages are to be
constructed, documented, and deployed.
http://www.bioconductor.org/developers/package-guidelines/
The only thing about bugs is: Response to bug reports and questions from users
regarding your package as posted
I’m also having issues with my bridges. It seems that they always “die" after
the initial sync (which for me is always a Git win). After awhile when I commit
again to GitHub, nothing happens on the SVN, and I end up deleting the bridges
and re-creating them. This always does the trick, but when
On 05/23/2014 11:20 AM, Ryan C. Thompson wrote:
Here is my use case (relevant lines highlighted):
https://gist.github.com/anonymous/0cd0c926fb21a8d62fcc#file-annotatepeaks-r-L49-L54
The idea is to annotate each peak with the Entrez ID of the nearest
transcription start site. Each Entrez ID can
Do we really need a centralized bug-tracker or would it be best to leave
that to the individual packages, e.g., using the github tracker via the
github-svn-bridge? Many are probably already doing that.
Michael
On Fri, May 23, 2014 at 11:16 AM, Cook, Malcolm wrote:
> Martin,
>
> I'm sure you'r
Here is my use case (relevant lines highlighted):
https://gist.github.com/anonymous/0cd0c926fb21a8d62fcc#file-annotatepeaks-r-L49-L54
The idea is to annotate each peak with the Entrez ID of the nearest
transcription start site. Each Entrez ID can have multiple transcripts,
hence multiple TSS,
Martin,
I'm sure you're watching this thread.
Can we take it as some "feedback from other developers" that you requested way
back in https://stat.ethz.ch/pipermail/bioc-devel/2011-October/002854.html when
I wished for similar
In any case,
+1,
Malcolm
>-Original Message-
>
Hi Ryan,
On 05/22/2014 03:38 PM, Ryan C. Thompson wrote:
Hello,
I recently found myself in want of a nearest method that handles
GRangesList objects. Is there any plan to add one?
Not that I know of. I guess most of the times it's probably good enough
to call range() on both GRangesList objec
Hi Nico,
It's a shame that the effort did not gain more traction in 2004. I wonder
if things would look differently now as the community has grown
significantly larger?
It does seem like there are a relatively small number of bug-related
questions on the mailing lists. I wonder though if this cou
Excellent, thanks! =)
On Thu, May 22, 2014 at 3:20 PM, Tengfei Yin wrote:
> thanks Dan, confirmed, 1.7.2 available as source, after run
> biocLite("OrganismDbi", type = "source")
>
> it works now!
>
>
> On Thu, May 22, 2014 at 3:12 PM, Dan Tenenbaum wrote:
>>
>> OrganismDbi 1.7.2 (available via
19 matches
Mail list logo
