Hi Boosters! While trying to trace the development of some boost libraries I see opportunities for improvement concerning the boost data distribution system. I am a little bit tired of looking up 3 or 4 different places in order to find out how some code snippet or library part under development is distributed, whether it is commited to the sandbox cvs, the vault, or stored hidden below boost-consulting.com (like SummerOfCode stuff with only a mailing list post pointing to it) or whether the developer has deliberately choosen to set up his own cvs/svn tree or other distribution method e.g. via sourceforge (which might be perfectly OK, Joel!). Yet I am missing the single entry point to all these GoodThings. Things are suboptimal: Example 1: Try to find out via boost web pages where one can download the latest and greatest version of boost::fusion. You can find a version at http://spirit.sourceforge.net/, but I am unsure if it is the latest bleeding edge version ... Example 2: Function types is under review. The files are accessible via tinyurl, so boost ML content is not self-contained. If I look at it in 6 years (when bought tinyurl and crashed the database), I will not be able to find any hint to where to find the files. Also if I'd like to see how that lib looked like at the time of review in order to understand the review discussion on the mailing list I am out of luck. Example 3: files in the vault are rather volatile, no file history available. Still waiting to obtain some old files mentioned in some post ... I'd like to make proposals for improvement: 1. Rule: Libraries under review _must_ be commited to cvs/svn tree of boost or boost-sandbox. In order to help people behind firewalls and resistent IT administrators, a script creates daily snapshots of cvs/svn tree which are accessible via ftp/http from boost.org similar to the way gcc is distributed. If a developer has no access via cvs/svn he/she has to find someone who can take this task (or boost has a server which provides svn on port 80 ...) Any announcement concerning reviews points to the ftp/http access point and contains the cvs/svn command which has to be used in order to obtain the files. Rationale: KISS for users. Blindly trust to find the code at one single point. 2. Rule: Posts to boost ML which link to any code snippet or fileset uploaded to the vault for discussion use a http link to the true URL at boost::vault. Using the full link is declared as netiquette rule for posting to ML. Rationale: Internet data is not persistent. A full link gives you the chance to find the file either by contacting the admin of the mentioned http server or by filename via standard search engines. 3. Technical measure: The vault is under some automatic version control (http://subversion.tigris.org/faq.html#filesystem http://noedler.de/projekte/wdfs/ http://svnbook.red-bean.com/en/1.1/apcs03.html) and versions can be retrieved via http on a per date basis, which allows to follow older discussions easily. Rationale: I recently read a discussion between Jeremy S., Joel d. G. and Dave A. which was hard to follow anyway due to the subject and due to the skill level of those who were talking. It would be much easier to get at least some minimal insight into what they were talking about if the files were still available (so I hope). Sometimes it really helps to read early stage code that is not yet polluted by all this CIRCUMVENT_BROKEN_COMPILER macros. [sidenote: looking forward to the new book: "The design and evolution of boost::mpl, boost::fusion, boost::graph and 12 other libraries" including all the chapters Dave and Alex left out in their first book ;-P] What do you think? Markus