[Rd] Community Feedback: Git Repository for R-Devel

[Juan Telleria]

########################################################################################################################################
# R-devel Archives: “Why R-project source code is not on Github"
[Summary: Aug 2014]
########################################################################################################################################

Key Citations (Pros and Cons) from R-devel Archives

########################################################################################################################################
# GIT PROS
########################################################################################################################################

1. [Simon Urbanek R-devel Aug 21, 2014] Github just makes it much
easier to create and post patches to the project - it has nothing to
do with write access - typically on Github the community has no write
access, either.

2. [Simon Urbanek R-devel Aug 21, 2014] Using pull requests is
certainly much less fragile than e-mails and patches are based on
forked branches, so you can directly build the patched version if you
want without manually applying the patch - and you see the whole
history so you can pick out things logically.

3. [Simon Urbanek R-devel Aug 21, 2014] You can comment on individual
patches to discuss them and even individual commits - often leading to
a quick round trip time of revising it.

4. [Yihui Xie-2 R-devel Aug 22, 2014] Sometimes the patches are not
worth emails back and forth, such as the correction of typos. I cannot
think of anything else that is more efficient than being able to
discuss the patch right in the lines of diff's.

5. [Gaurav Sehrawat R-devel Aug 24, 2014] Bridging gap between web2.0
and web1.0 development methodologies  & thus passing code to younger
generation .

6. [Jeroen Ooms. R-devel Aug 24, 2014] By now all activity of r-base
[1] cran [2] and r-forge [3] is
continuously mirrored on Github, which already gives unprecedented
insight in developments. At least several r-core members [4,5,6,7,8]
have been spotted on Github, and this years useR2014 website [9] was
developed and hosted completely on Github. It seems like a matter of
time until the benefits outweigh the cost of a migration, even to the
more conservative stakeholders.

7. [Spencer Graves-2 R-devel Aug 24, 2014] We could use Git without
Github (Gitlab, …)

8. [Spencer Graves-2 R-devel Aug 24, 2014] It should be easy and cheap
for someone to program a server to make daily backup copies of
whatever we want from Github.  This could provide an insurance policy
in case events push the group to leave Github.

9. [Brian Rowe R-devel Aug 24, 2014] One thing to note about git vs
svn is that each git repository is a complete repository containing
the full history, so despite github acting as a central repository, it
is not the same as a central svn repository. In svn the central
repository is typically the only repository with a complete revision
history, but that is not the case with git.

10. [Simon Urbanek R-devel Aug 25, 2014] There is no point in using
git alone (Github actually supports direct SVN access as well).

11. [Simon Urbanek R-devel Aug 25, 2014] Github: The whole point are
the collaborative features.

########################################################################################################################################
# GIT CONS
########################################################################################################################################

1. [Marc Schwartz R-devel Aug 21, 2014] Since the current SVN based
system works well for them (R Core) and provides restricted write
access that they can control, there is no motivation to move to an
alternative version control system unless they would find it to be
superior for their own development processes.

2. [Jeroen Ooms. R-devel Aug 24, 2014] These things take time

3. [Jeroen Ooms. R-devel Aug 24, 2014] However moving development of a
medium sized, 20 year old open source project is not trivial. You are
dealing with a large commit history and many contributors that all
have to overhaul their familiar tools and development practices
overnight.

4. [Jeroen Ooms. R-devel Aug 24, 2014] There is also the
infrastructure of nightly builds and CRAN r-devel package checking
that relies on the svn.

5. [Jeroen Ooms. R-devel Aug 24, 2014] Moreover moving to Github means
changes in communications, for example replacing the current bug
tracking system to Github "issues".

6. [Jeroen Ooms. R-devel Aug 24, 2014] In addition, several members
are skeptical about putting source code in the hands of a for-profit
US company, and other legal issues.

7. [Jeroen Ooms. R-devel Aug 24, 2014] The most critical piece of
making such a transition is a detailed proposal outlining what the
migration would involve, the cost/benefits, a planning, and someone
that is willing to take the lead. Only on the basis of such a serious
proposal you can have a discussion in which everyone can voice
concerns, be assured that his/her interests are secure, and the idea
can eventually be put up for a vote.

8. [Kirill Müller. Jan 05, 2018 (With Permission)] Migration Technical Problems:
- Keeping monotonous revision numbers seems to be a requirement for
migrating to GitHub.
- It may be more difficult to apply patches produced by "git
format-patch" or "git diff" (obtained from Winston's GitHub mirror) to
an SVN working copy, because patches created by Git are missing the
SVN base revision. (This is an obstacle to adopting GitHub gradually.)

* NOTE: Paper (Previous Transition Experience):
http://iopscience.iop.org/article/10.1088/1742-6596/898/7/072024/pdf