Folks, it appears that at present, our SVN sandbox is in fairly confused state. A fresh checkout contains objects of very different kinds, in particular: - 'boost' directory, that has assorted headers supposedly meant for future. - 'libs' directory, with various libraries - Pile of top-level directories for libraries-in-development, each containing 'boost' and 'libs' subfolders. - Subdirectory SCons, with a copy of entire Boost tree, buildable with scons. - Subdirectory 'win32-doc-tools', which surely does not contain a library - Some directories named after specific people. It's not clear whether those directories contain a single future library, or several, or what. It seems that a straight-forward approach to fix that is to have two separate areas in sandbox, as follows: [using fixed font to read the below might work better] /sandbox /libraries /proposed-lib1 /boost /libs .... /branches /jrhacker-assorted-fixes [complete branch of trunk, with changes] /SCons [complete branch of trunk, with SConstruct, etc] Comments? -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2
Vladimir Prus wrote:
- 'boost' directory, that has assorted headers supposedly meant for future.
- 'libs' directory, with various libraries
Both directories are deprecated since a long time. I think it is now the time to explicitly send notices to the very few developers that still keep using the boost and libs directories. Maybe we could then move the "boost" and "libs" directories to an "old" or "deprecated" folder, to really be explicit about their status.
/sandbox /libraries /proposed-lib1 /boost /libs
The currently agreed structure (<http://www.boost.org/community/sandbox.html>) is /sandbox /proposed-lib1 /boost /libs If the only reason to change this structure is that a few developers failed to follow that structure, this doesn't seem fair to the vast majority of developers that tried to follow that structure. Each change of structures is potentially confusing for the users of a sandbox library, especially if there are already too many different versions of the library out there anyway. And it will invalidate links given in archived email answers to user questions.
/branches
This sounds like a good idea to me.
Comments?
If we are unhappy with the current situation, I suggest we could change the statement "We encourage developers to migrate these projects to the project-centric organizational structure." from <http://www.boost.org/community/sandbox.html> to something more mandatory. Regards, Thomas
Thomas Klimpel wrote:
Vladimir Prus wrote:
- 'boost' directory, that has assorted headers supposedly meant for future.
- 'libs' directory, with various libraries
Both directories are deprecated since a long time. I think it is now the time to explicitly send notices to the very few developers that still keep using the boost and libs directories. Maybe we could then move the "boost" and "libs" directories to an "old" or "deprecated" folder, to really be explicit about their status.
/sandbox /libraries /proposed-lib1 /boost /libs
The currently agreed structure (<http://www.boost.org/community/sandbox.html>) is
/sandbox /proposed-lib1 /boost /libs
If the only reason to change this structure is that a few developers failed to follow that structure, this doesn't seem fair to the vast majority of developers that tried to follow that structure. Each change of structures is potentially confusing for the users of a sandbox library, especially if there are already too many different versions of the library out there anyway. And it will invalidate links given in archived email answers to user questions.
+1
/branches
This sounds like a good idea to me.
Well this has the same link problem as moving to the proposed libraries to /libraries. I would place here branches of accepted libraries with a big development, to make clear what is a proposal and what is already accepted. The Vault could also follow a clean-up, and replace files that have already been integrated in Boost, as it was done for xpressive, ...
Comments?
If we are unhappy with the current situation, I suggest we could change the statement "We encourage developers to migrate these projects to the project-centric organizational structure." from <http://www.boost.org/community/sandbox.html> to something more mandatory.
+1 Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Sandbox-cleanup-tp3063197p3064101.html Sent from the Boost - Dev mailing list archive at Nabble.com.
On 11/29/2010 3:27 AM, Vladimir Prus wrote:
Folks,
it appears that at present, our SVN sandbox is in fairly confused state. A fresh checkout contains objects of very different kinds, in particular:
- 'boost' directory, that has assorted headers supposedly meant for future.
- 'libs' directory, with various libraries
- Pile of top-level directories for libraries-in-development, each containing 'boost' and 'libs' subfolders.
- Subdirectory SCons, with a copy of entire Boost tree, buildable with scons.
- Subdirectory 'win32-doc-tools', which surely does not contain a library
- Some directories named after specific people. It's not clear whether those directories contain a single future library, or several, or what.
It seems that a straight-forward approach to fix that is to have two separate areas in sandbox, as follows:
[using fixed font to read the below might work better]
/sandbox /libraries /proposed-lib1 /boost /libs
....
/branches /jrhacker-assorted-fixes [complete branch of trunk, with changes] /SCons [complete branch of trunk, with SConstruct, etc]
Comments?
Only that developers should use the correct structure, where the /boost and /libs subdirectories exist under each individual library, and that their appears to be many libraries in the sandbox that are obsolete in the sense that the library is already in Boost but files are still lying around in the sandbox. How and if the latter can be cleaned up I have no idea. As for the former, maybe Boost should enforce the fact that individual libraries must use their own /boost and /libs subdirectory since the general /boost and /libs directories will be removed at some future date and all the libraries within these directories will be moved to their own individual library. I too find the sandbox to be pretty messy, but I find it even more annoying when proprosers of possible libraries to Boost put their code in some other arcane place on the Internet rather than in the sandbox. So it would be nice if the sandbox could be regularized and cleaned up.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: Monday, November 29, 2010 3:14 PM To: boost@lists.boost.org Subject: Re: [boost] Sandbox cleanup
On 11/29/2010 3:27 AM, Vladimir Prus wrote:
Folks,
it appears that at present, our SVN sandbox is in fairly confused state. A fresh checkout contains objects of very different kinds, in
Comments?
Only that developers should use the correct structure, where the /boost and /libs subdirectories exist under each individual library, and that their appears to be many libraries in the sandbox that are obsolete in the sense that the
particular: library is
already in Boost but files are still lying around in the sandbox.
How and if the latter can be cleaned up I have no idea. As for the former, maybe Boost should enforce the fact that individual libraries must use their own /boost and /libs subdirectory since the general /boost and /libs directories will be removed at some future date and all the libraries within these directories will be moved to their own individual library.
I too find the sandbox to be pretty messy, but I find it even more annoying when proprosers of possible libraries to Boost put their code in some other arcane place on the Internet rather than in the sandbox. So it would be nice if the sandbox could be regularized and cleaned up.
It would be *very* nice if every library followed the correct structure so it can be moved easily to trunk or a release download. I believe the current hassle involved in this is a real impediment to getting reviewers. So I think we should begin to make 'tough' noises ;-) Perhaps one the Boost.Guild people could take it on themselves to start by contacting offending authors? And a full description for would-be/existing author of *exactly* what the structure must be (with examples) would be good too. Being able to provide a link to a 'how-to' documentation might resolve the obvious confusion about this. (Aside: The structure seems quite dotty to me - perhaps someone can provide a rationale? But even if that rationale is lost in the mists of time, we have a standard, and a standard is what we must all follow, however peculiar.) Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 11/29/2010 12:44 PM, Paul A. Bristow wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: Monday, November 29, 2010 3:14 PM To: boost@lists.boost.org Subject: Re: [boost] Sandbox cleanup
On 11/29/2010 3:27 AM, Vladimir Prus wrote:
Folks,
it appears that at present, our SVN sandbox is in fairly confused state. A fresh checkout contains objects of very different kinds, in
particular:
Comments?
Only that developers should use the correct structure, where the /boost and /libs subdirectories exist under each individual library, and that their appears to be many libraries in the sandbox that are obsolete in the sense that the library is already in Boost but files are still lying around in the sandbox.
How and if the latter can be cleaned up I have no idea. As for the former, maybe Boost should enforce the fact that individual libraries must use their own /boost and /libs subdirectory since the general /boost and /libs directories will be removed at some future date and all the libraries within these directories will be moved to their own individual library.
I too find the sandbox to be pretty messy, but I find it even more annoying when proprosers of possible libraries to Boost put their code in some other arcane place on the Internet rather than in the sandbox. So it would be nice if the sandbox could be regularized and cleaned up.
It would be *very* nice if every library followed the correct structure so it can be moved easily to trunk or a release download.
I believe the current hassle involved in this is a real impediment to getting reviewers.
So I think we should begin to make 'tough' noises ;-)
Perhaps one the Boost.Guild people could take it on themselves to start by contacting offending authors?
And a full description for would-be/existing author of *exactly* what the structure must be (with examples) would be good too.
Being able to provide a link to a 'how-to' documentation might resolve the obvious confusion about this.
(Aside: The structure seems quite dotty to me - perhaps someone can provide a rationale?
But even if that rationale is lost in the mists of time, we have a standard, and a standard is what we must all follow, however peculiar.)
I do not have a rationale but the structure appears correct to me and not "quite dotty" <g>, but a valid attempt to emulate a Boost distribution. In that rcommended structure under each library in the sandbox there is a 'boost' directory, equivalent to the 'boost' directory in a Boost distribution tree, and a 'libs' directory, equivalent to a 'libs' directory in a Boost distribution tree. All the end-user has to do, for a given sandbox library, is copy ( or move ) everything below a given library's top directory to the root of a Boost distribution tree if he/she wants to integrate it in with a particular Boost distribution ( most usually the latest Boost distribution in the SVN trunk ), and everything for that sandbox library should work as is. Actually since the sandbox is distributed under SVN, the proper thing to do if moving it below an SVN Boost trunk distribution, as I have since learned, is an SVN export, rather than a physical copy or move, for each of the 'boost' and 'libs' subdirectories so as not to replace the .svn files in a Boost trunk distribution. At the same time, with the proper jam files for a sandbox library, as shown by Daniel James; 'example' sandbox library, one should also be able to use the library as is wherever one originally puts it, by specifying a Boost distribution using the 'bjam' option of '--boost=path/to/boost/distribution' when executing a sandbox jam file for building, testing, or docs.
On 1:59 PM, Paul A. Bristow wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: Monday, November 29, 2010 3:14 PM To: boost@lists.boost.org Subject: Re: [boost] Sandbox cleanup
On 11/29/2010 3:27 AM, Vladimir Prus wrote:
Folks,
it appears that at present, our SVN sandbox is in fairly confused state. [...] So it would be nice if the sandbox could be regularized and cleaned up. [...]
Perhaps one the Boost.Guild people could take it on themselves to start by contacting offending authors?
I'll put that on Boost.Guild's list, but I think the Guild's first priority is the quality of Boost proper. Hopefully the Guild will attract enough volunteers to do it all. Hopefully.
Paul A. Bristow wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: Monday, November 29, 2010 3:14 PM To: boost@lists.boost.org Subject: Re: [boost] Sandbox cleanup
On 11/29/2010 3:27 AM, Vladimir Prus wrote:
Folks,
it appears that at present, our SVN sandbox is in fairly confused state. A fresh checkout contains objects of very different kinds, in
particular:
Comments?
Only that developers should use the correct structure, where the /boost and /libs subdirectories exist under each individual library, and that their appears to be many libraries in the sandbox that are obsolete in the sense that the library is already in Boost but files are still lying around in the sandbox.
How and if the latter can be cleaned up I have no idea. As for the former, maybe Boost should enforce the fact that individual libraries must use their own /boost and /libs subdirectory since the general /boost and /libs directories will be removed at some future date and all the libraries within these directories will be moved to their own individual library.
I too find the sandbox to be pretty messy, but I find it even more annoying when proprosers of possible libraries to Boost put their code in some other arcane place on the Internet rather than in the sandbox. So it would be nice if the sandbox could be regularized and cleaned up.
It would be *very* nice if every library followed the correct structure so it can be moved easily to trunk or a release download.
I believe the current hassle involved in this is a real impediment to getting reviewers.
So I think we should begin to make 'tough' noises ;-)
Perhaps one the Boost.Guild people could take it on themselves to start by contacting offending authors?
Uhm, is this really necessary? We will never cleanup sandbox if we wait for OK from anybody who ever comitted anything. After all, it's only sandbox, and the proposal is to move things around, not to remove or change in unobvious ways. So, can we just agree on layout, and then I can do "svn mv" as necessary? In fact, it's probably easier than I though. We have both /sandbox and /sandbox-branches. So, how about this: 1. Declare that /sandbox should follow <library>/{boost,libs} layout. 2. Move everything else into /sandbox-branches ? - Volodya
Uhm, is this really necessary? We will never cleanup sandbox if we wait for OK from anybody who ever comitted anything. After all, it's only sandbox, and the proposal is to move things around, not to remove or change in unobvious ways.
Maybe it is possible and polite to check at least the authors which recently (f.e. last month) committed something.
So, can we just agree on layout, and then I can do "svn mv" as necessary?
In fact, it's probably easier than I though. We have both /sandbox and /sandbox-branches. So, how about this:
1. Declare that /sandbox should follow<library>/{boost,libs} layout. 2. Move everything else into /sandbox-branches
Boost.Geometry follows <library>/{boost,libs,other} layout where other contains small programs not fitting within libs. I hope this is permitted. I'm quite dependent on the current place and so are many users. I will remove the (now obsolete) ggl folder which is still there. Maybe it is also possible (now or in the future) to make a distinction between already-accepted-but-not-yet-incorparted libraries (such as Boost.Geometry) and proposed libraries. Finally there is also /sandbox-tags, of which the structure is also not so clear to me. I've taken the freedom to create a "geometry" folder there, and below that are our tags. So the there structure is for me: /sandbox-tags/<library>/<tagname>/{boost,libs} And I propose that as a convenient layout. Regards, Barend
Vladimir Prus wrote:
Uhm, is this really necessary? We will never cleanup sandbox if we wait for OK from anybody who ever comitted anything. After all, it's only sandbox, and the proposal is to move things around, not to remove or change in unobvious ways.
The only remaining "recently" active projects in boost/libs seem to be mapreduce algorithm + minmax_macro extension reflection It probably won't be too difficult to contact the corresponding authors.
So, can we just agree on layout, and then I can do "svn mv" as necessary?
In fact, it's probably easier than I though. We have both /sandbox and /sandbox-branches. So, how about this:
1. Declare that /sandbox should follow <library>/{boost,libs} layout. 2. Move everything else into /sandbox-branches
+1
?
We should probably extend <http://www.boost.org/community/sandbox.html> to mention "sandbox-branches" / "sandbox-tags" and explain how those are intended to be used. Because, if I understood you correctly, you also want to move the subdirectory "SCons" to branches, as well as the "Some directories named after specific people." On the other hand, I hope we agree that it's OK that projects (subdirectories) like "boost_docs", "committee", "documentation", "SOC", "win32-doc-tools" (and other similar projects I missed) will stay where they currently are, and that we also agree that it's OK for similar project in the future to follow the example of these projects. Since these projects are not libraries, and don't include a complete clone/branch of trunk, it only seems fair to treat them in a similar way as the libraries are treated. One remaining issue is that many libraries currently have the structure <library>/{boost,libs,branches} My personal opinion is that this is OK, since I never saw that "sandbox-branches" was advertised instead. So if we would want to change this, we should start with a phrase like "We encourage developers to migrate ..." on <http://www.boost.org/community/sandbox.html>, and then wait for some years before we take any further action on this. Regards, Thomas
participants (8)
-
Barend Gehrels -
Edward Diener -
Jim Bell -
Paul A. Bristow -
Thomas Klimpel -
Vicente Botet -
Vladimir Prus -
Vladimir Prus