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
reasonable low bar.


On Fri, May 23, 2014 at 1:41 PM, Sean Davis <sdavis2@mail.nih.gov> wrote:

> On Fri, May 23, 2014 at 4:34 PM, Michael Lawrence
> <lawrence.michael@gene.com> 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 to github
> via a
> > web API to pre-populate, but it's a slippery slope and I'm not sure if we
> > want to invest in a full bug tracking abstraction. Not only would you
> need
> > to worry about filing bugs, but also searching them (to avoid
> duplication),
> > and watching/monitoring them.  Would rather leave all that to the
> trackers
> > and assume users are comfortable using a web browser, which we would
> > probably use for prompting the user anyway.
>
> You gotta love the R community!  If one restricts things to github,
> this is potentially useful.
>
> https://github.com/cscheid/rgithub
>
> And specifically:
>
> https://github.com/cscheid/rgithub/blob/master/R/issues.R
>
> >
> >
> >
> >
> >
> > On Fri, May 23, 2014 at 1:24 PM, Vincent Carey
> > <stvjc@channing.harvard.edu>wrote:
> >
> >> 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 could prompt for
> >> specifics.  bug data could be centralized and decentralized depending on
> >> how these tools are crafted.
> >>
> >>
> >> On Fri, May 23, 2014 at 4:10 PM, Yihui Xie <xie@yihui.name> wrote:
> >>
> >>> 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 <xieyihui@gmail.com>
> >>> Web: http://yihui.name
> >>>
> >>>
> >>> On Fri, May 23, 2014 at 2:58 PM, Dan Tenenbaum <dtenenba@fhcrc.org>
> >>> wrote:
> >>> >
> >>> >
> >>> > ----- Original Message -----
> >>> >> From: "Michael Lawrence" <lawrence.michael@gene.com>
> >>> >> To: "Kasper Daniel Hansen" <kasperdanielhansen@gmail.com>
> >>> >> Cc: "Michael Lawrence" <lawrence.michael@gene.com>,
> >>> 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 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.
> >>> >
> >>> > Already done; see for example the ACME package landing page:
> >>> >
> >>> > http://www.bioconductor.org/packages/release/bioc/html/ACME.html
> >>> >
> >>> > The URL is a clickable link. This could be the link to the github
> issue
> >>> tracker. Note that you can have multiple URLs in the URL field, I
> believe
> >>> comma separated. See also
> >>> > http://www.bioconductor.org/developers/how-to/git-svn/#advertise
> >>> >
> >>> > Dan
> >>>
> >>> _______________________________________________
> >>> Bioc-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>>
> >>
> >>
> >
> >         [[alternative HTML version deleted]]
> >
> > _______________________________________________
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

	[[alternative HTML version deleted]]

