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.wick...@gmail.com> wrote: > On Tue, May 26, 2015 at 12:18 PM, Gabriel Becker <gmbec...@ucdavis.edu> > wrote: > > On Tue, May 26, 2015 at 9:25 AM, Yihui Xie <x...@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]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel