R devel - Mar 2013 - the case of building R snapshot without svn nor network connection.

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. 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".

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

I'll quantify the first part - R is perhaps the only public software project
hosted on a subversion repository for which the result of 'svn export
...' does not build. Not only that it does not build, but make it a feature
that it does not build.

Very few other projects actively try to go in that direction.

--- On Fri, 15/3/13, Hin-Tak Leung <hintak_leung at yahoo.co.uk> 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. 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".
>