On Tue, May 26, 2015 at 10:46 AM, Gabriel Becker <gmbec...@ucdavis.edu> wrote: > 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.
The same problem exists for CRAN (and for some of the Bioconductor packages), i.e. the "source" tarballs (*.tar.gz files) on the repository are often mistakenly seen as the main/root source of the package. The risk for this is less so when the package maintainer share the source on a public version control system. I think of CRAN as an archive of specific package versions. I look at Gabor's MetaCRAN exactly the same way. (I agree that the concept of a "commit" may be confusing though, where it should really be a "release"). /Henrik > > 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
