On 12/31/2013 06:50 AM, Vladimir Prus wrote:
On 31.12.2013 16:43, Peter A. Bigot wrote:
On 12/31/2013 02:17 AM, Vladimir Prus wrote:
On 30.12.2013 23:43, Peter A. Bigot wrote:
IOW, this requirement may not actually impact many people, especially if testing is normally done in cloud VMs rather than on development machines.
Why do you assume that testing happens on cloud VMs?
I don't. I thought I recently saw some discussion of how to set up a VM to support the new scripts, so I tried to address that.
Updating a package on a development machine beyond what the vendor provides introduces risk. What I meant to convey was, git version requirements of a specific test-framework script need not affect people who do not run that script, and if that's most people then the risk is limited. Having a set of standard VM configurations for testing (on the cloud or locally) also mitigates the risk.
In this context (a git dependency in regression.py), I am also specifically referring to super-project regression testing, a subset of testing that is primarily important for integration verification. Continuous integration should be a Boost process goal given its governance model, and CI is rarely done on a developer's desktop. I would expect Boost to move toward doing regression testing on VMs, perhaps on a hosted service like travis-ci.org which is free for open source projects and has decent github integration.
I think there's a difference between a model we'd use given infinite resources, and the practical situation - where getting releases tested and created is complicated. Having to build and install extra-fresh version of git just makes it more complicated.
As I understand it, the new requirement derives from a desire to speed up the time it takes to get the test workspace. This is done by cloning only the tested branch of every submodule from the master repositories on github, which requires the new switch so unwanted revisions aren't transferred. This itself is an extremely heavyweight operation, and reworking the regression script so it first updates a local set of repositories then clones from that would eliminate both the need for the git upgrade and the unnecessary network transfers. In fact, the only argument I imagine I saw for not doing that in the first place was a desire to run in a VM that was reset to a state where it didn't have the repositories already available. (On systems that support hard links, cloning a repository on the same file system does not replicate the metadata and is a very cheap operation.) Peter