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/
On Tue, May 26, 2015 at 1:26 PM, Hadley Wickham <h.wickham at gmail.com> wrote:> > 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. >Exactly. Even if the original repo is on GitHub, I want to use one under github.com/cran. Actually, I don't even want to fork the original repo, because I want the github.com/cran repos to look the same: one commit per package version, tagged with the version number. This way it is easy to compare different versions of a package, easy to link to the code of a specific version, etc. If I link to the original repo, then I need the maintainer to tag releases properly, etc. Many of them do, but still, I don't want to rely on that. I obviously want to send potential contributors to the original upstream repo, and I think I can do a better job at that, with warnings both on the web page and in the github.com/cran repos. E.g. on the web page, we can have a "Contribute" button, that goes upstream. On the cran GH page I can have a warning line on top, with the link to the original repo. Gabor [[alternative HTML version deleted]]
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 aboutthis 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]]
On Tue, May 26, 2015 at 1:46 PM, Gabriel Becker <gmbecker at ucdavis.edu> wrote:> That's true, but issues, checkouts, comments, credit, etc should all be > going to the original repo.You mean the links? They are, aren't they? [...]> >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. >I cannot do much about that. Issues and wiki are turned off, but you cannot turn off forking or pull requests. Even the official mirrors at GitHub have them, e.g. the Apache Spark mirror at https://github.com/apache/spark And I don't actually want to turn off forks for these repos, because they are useful for repos that are originally not on CRAN. Anyway, in summary I'll try to do a better job at directing people to the original sources. Gabor [...] [[alternative HTML version deleted]]
On Tue, May 26, 2015 at 10:46 AM, Gabriel Becker <gmbecker at 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.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]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel