[Rd] MetaCran website v1.0.0-alpha

Henrik Bengtsson henrik.bengtsson at ucsf.edu
Tue May 26 22:44:36 CEST 2015


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



More information about the R-devel mailing list