[Rd] MetaCran website v1.0.0-alpha

[Gabriel Becker]

That's true, but issues, checkouts, comments, credit, etc should all be
going to the original repo. Anything else seems grossly unfair to the
package author(s). This issue is exacerbated even further when the the
author isn't developing the package on github at all, and github users may
unintentionally begin to view the forks as the actual canonical sources for
the package.

Also, the archive use-case, while near and dear to my own heart, seems
explicitly different from the "look at the package as it is now" use-case
that the forks are actually being used for.

To be clear, I think a lot of the metacran stuff is great. I use the APIs
myself and Gabor's work on this stuff is great.  I just think there are
some pitfalls here.

>From the email Gabor just sent out, it sounds like he and I agree about
this stuff anyway. I was really responding to the proposal that the
repositories actually be forked.

~G

On Tue, May 26, 2015 at 10:26 AM, Hadley Wickham <h.wickham at gmail.com>
wrote:

> On Tue, May 26, 2015 at 12:18 PM, Gabriel Becker <gmbecker at ucdavis.edu>
> wrote:
> > On Tue, May 26, 2015 at 9:25 AM, Yihui Xie <xie at yihui.name> wrote:
> >
> >> I cannot speak for other package authors, but for all my own packages,
> >> I have provided the BugReports field in DESCRIPTION that points to the
> >> Github issues page. You can probably use this field to check if a
> >> package is on Github or not. If it is, you may just fork the original
> >> repo instead of creating a new one from the CRAN package.
> >
> >
> > Maybe I'm missing something, but why would you fork the repo instead of
> > just using the existing repo?
>
> One advantage of a fork is that you have permanent archive even if the
> original goes away.
>
> Hadley
>
> --
> http://had.co.nz/
>



-- 
Gabriel Becker, PhD
Computational Biologist
Bioinformatics and Computational Biology
Genentech, Inc.

	[[alternative HTML version deleted]]