######################################################################################################################################## # 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
