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
