On Mar 15, 2013, at 7:29 PM, Hin-Tak Leung wrote: > The decision to actively discourage non-subsersion usage of snapshot build is > already made (r62183). So I am just here to register a differing opinion. > > - it is not about subversion vs other-version-control-tools. There are two > parts of R's dev build process which requires an active network connection - > tools/rsync-recommended and capturing `svn info` into R's headers.
That is a false statement - svn info doesn't require any network connection. Cheers, Simon > The former can be overridden with "./configure > --with-recommended-packages=no". A few changes had been made in the last 6 > months to make the latter mandatory. It used to be optional. > > --- there are genuine needs for testing snapshots in a non-networked > minimalist environment - e.g. banks or telecom industries - where one wants a > "standardised host" build, and often it means an "outdated host"; or in a > virtual machine environment - which are non-networked for security reasons, > and also do not have tools beyond necessary for compiling and building. This > is quite a common scenario. > > --- AFAIK, 6 months ago, a snapshot copied to an non-networked host will > build with "./configure --with-recommended-packages=no". Of course copying > those recommended package tar balls across would be nicer. This is sadly no > longer the case. > > - dependent on `svn info` and sitting on top of a svn checkout possibly also > affects cross-compiling. But then, it is not clear whether it is still > possible to cross-compile R, since quite a few changes have been made to > remove the capability of cross-compiling R for windows on unix hosts in the > last few years. > > - testing dev snapshots is about trying things and fixing bugs before > release. Making it difficult for non-core people to "try", seem to go against > that ethos. If that's the case, maybe the repository could be closed off to > anonymous check outs altogether, just to make it clear that testing snapshots > before releases or even close to release, is not welcomed. Just a thought. > > - although the official repository of the "main" linux kernel branch is > git-based, there are mercurial mirrors; AFAIK the digital video broadcasting > hardware support of the linux kernel is officially in mercurial repositories, > but have git mirrors; likewise much of Xorg's is in mercurial but have git > mirrors. I haven't heard of any much bigger public projects than R where some > actively discourage others. > > - To be honest r62183 itself is probably a good reason to move away from > server-side repositories to distributed repositories (hg/git/arch/bzr). Local > enhancements - i.e. an in-house fork - some of which are never going > upstream, such as a local revert of r62183 (or a local revert of any other > upstream commits) is one reason why some have distributed repositories. > > Lastly, a minor grip. The current head of the HK government is probably > sometimes called "HK Leung", just as some might call a certain old lady "UK > Windsor" and a certain black person "US Obama". > > ______________________________________________ > 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
