[vault] or maybe sandbox?
I am unclear of what the vault contains, and of its relation to the sandbox. The sandbox is a versioned repository, whereas the the vault appears not to be. What is the workflow here, if there is one? By what path do libraries arrive at Boost proper (ie. part of some release), and where in the process are the review points? Thanks, Rob.
Robert Jones wrote:
I am unclear of what the vault contains, and of its relation to the sandbox.
The sandbox is a versioned repository, whereas the the vault appears not to be.
What is the workflow here, if there is one? By what path do libraries arrive at Boost proper (ie. part of some release), and where in the process are the review points?
Both the vault and the sandbox provide alternative means developers can use to make code still in development available: the vault provides zip file downloads while the sandbox provides full version control when that's more applicable. Developers producing code for Boost are free to use either, both or neither depending on preference :-) However, once a library has matured to the point that the author would like it to become an official part of Boost, then they ask for a formal review of the code (http://www.boost.org/development/submissions.html), and generally also make a zip file available for download from the vault (just because it's more convenient for potential reviewers that way). Once code has been accepted into Boost and is in mainline SVN Trunk, some of us continue to use the sandbox for general development as well. To pick an example the Boost.Math special functions/distribution code has a branch in the sandbox: new "experimental" developments go here, as do submissions from new authors, then periodically when these are all looking stable they get merged to Trunk for full testing, and then when that's all looking OK, merged to the release branch for release. In contrast bug fixes to existing code, generally go straight into the Trunk so that users can use these right away, and likewise they tested in our test matrix right away. These get merged back into the sandbox development branch at the same time as sandbox changes are merged into Trunk. But anyhow, that's digressing from the question :-) HTH, John.
John Maddock wrote:
Robert Jones wrote:
I am unclear of what the vault contains, and of its relation to the sandbox.
The sandbox is a versioned repository, whereas the the vault appears not to be.
What is the workflow here, if there is one? By what path do libraries arrive at Boost proper (ie. part of some release), and where in the process are the review points?
Both the vault and the sandbox provide alternative means developers can use to make code still in development available: the vault provides zip file downloads while the sandbox provides full version control when that's more applicable. Developers producing code for Boost are free to use either, both or neither depending on preference :-)
I honestly do not see the point of having two different locations for putting nascent implementations for others who are interested to try out, which may eventually be submitted to Boost. I believe it would be much cleaner and clearer if there were a single path, which all end users could peruse, and that path had a regularized way for access both by the developer and the end user. Having two different places, and having implementations spread out in those places where they are hard to find and difficult to try out, does not help Boost in its incubation of new ideas and libraries based on those ideas. As someone who has at least thought of putting code somewhere 'out there' for other interested Boost end users to try, this shotgun approach of getting end users interested and uploading implementations 'somewhere' does not suit my approach to such a situation. For me a more logically rigorous "this is what you need to do" suits me much better.
John Maddock wrote:
However, once a library has matured to the point that the author would like it to become an official part of Boost, then they ask for a formal review of the code (http://www.boost.org/development/submissions.html), and generally also make a zip file available for download from the vault (just because it's more convenient for potential reviewers that way).
Just throwing out an idea: if (and I said "if" :-)) we agree to have the sandbox as the one place for "incubation", would it be possible, given the current Boost infrastructure, to provide something like SourceForge's "Download GNU tarball" link? -- Genny
on Fri Aug 29 2008, Gennaro Prota <gennaro.prota-AT-yahoo.com> wrote:
John Maddock wrote:
However, once a library has matured to the point that the author would like it to become an official part of Boost, then they ask for a formal review of the code (http://www.boost.org/development/submissions.html), and generally also make a zip file available for download from the vault (just because it's more convenient for potential reviewers that way).
Just throwing out an idea: if (and I said "if" :-)) we agree to have the sandbox as the one place for "incubation", would it be possible, given the current Boost infrastructure, to provide something like SourceForge's "Download GNU tarball" link?
Do you mean, a way to download a .zip snapshot of any given subdirectory of the sandbox? It's certainly possible. Probably it should be a Trac plugin. Hmm, I wonder if such a plugin exists already. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Fri Aug 29 2008, Gennaro Prota <gennaro.prota-AT-yahoo.com> wrote:
However, once a library has matured to the point that the author would like it to become an official part of Boost, then they ask for a formal review of the code (http://www.boost.org/development/submissions.html), and generally also make a zip file available for download from the vault (just because it's more convenient for potential reviewers that way). Just throwing out an idea: if (and I said "if" :-)) we agree to have
John Maddock wrote: the sandbox as the one place for "incubation", would it be possible, given the current Boost infrastructure, to provide something like SourceForge's "Download GNU tarball" link?
Do you mean, a way to download a .zip snapshot of any given subdirectory of the sandbox?
It's certainly possible. Probably it should be a Trac plugin. Hmm, I wonder if such a plugin exists already.
I already implemented downloading a TGZ of any subtree in the SVN repo as part of the regression testing. But I loath pointing it out to people as it's something that if used frequently increases the burden on the svn/web server. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
Just throwing out an idea: if (and I said "if" :-)) we agree to have the sandbox as the one place for "incubation", would it be possible, given the current Boost infrastructure, to provide something like SourceForge's "Download GNU tarball" link?
Do you mean, a way to download a .zip snapshot of any given subdirectory of the sandbox?
It's certainly possible. Probably it should be a Trac plugin. Hmm, I wonder if such a plugin exists already.
I already implemented downloading a TGZ of any subtree in the SVN repo as part of the regression testing. But I loath pointing it out to people as it's something that if used frequently increases the burden on the svn/web server.
To Dave: yes, that's what I meant. To Rene and everyone: would it be possible to enable it selectively? Perhaps only on sandbox/, or only some of its subdirectories. At "worst" just on the subdirectory for the library under review. -- Genny
participants (6)
-
David Abrahams -
Edward Diener -
Gennaro Prota -
John Maddock -
Rene Rivera -
Robert Jones