This page describes the process a library developer goes through to get a library accepted by Boost.
See the Boost Library Requirements and Guidelines page for issues of content.
Subscribe to the main developers mailing list for a while, or look through the archives. Click around the web site. Understand the Requirements. Read the rest of this page to learn about the process. Otherwise, you will just end up wasting everyone's time.
There is a culture associated with Boost, aimed at encouraging high quality libraries by a process of discussion and refinement.
If what you really want is a site that will just post your library without even looking at it, you should go elsewhere.
Potential library submitters should use the Boost developers mailing list as a forum to gauge interest a possible submission.
A message might be as simple as "Is there any interest in a library which solves Traveling Salesperson problems in linear time?"
A bit of further description or snippet of code may be helpful. Messages should be plain text; not rich text, HTML, etc.
Please don't post lengthy descriptions, documentation, or code to the mailing list, and no attachments, even small ones. Please post lengthy material in the boost Sandbox Vault.
If response to an initial query indicates interest, then post the preliminary submission files in the Sandbox Vault on the sourceforge web site if you haven't already done so.
Discuss, refine, resubmit. Repeat until satisfied.
The exact details of this process varies a lot. Sometimes it is public, on the mailing list, sometimes a lot of discussion happens in private emails. For some libraries the process is over quickly, for others it goes on for months. It's often challenging, and sometimes leads off in completely unexpected directions.
The archive of past messages is one way to see how this process worked for other Boost libraries.
All of the files which make up the library should be combined and compressed into a single submission file using the .zip format. Free encoders and decoders for this format running on many different platforms are available at the Info-ZIP web site, which includes a FAQ and much other useful information about the .zip format. Many commercial compressor-archiver utilities also support this format.
The submission file should contain material as if on the boost.org web site. The closer the submission file mirrors the final directory structure and format of the web site, the better.
Like a preliminary submission, post the final submission .zip file in the Sandbox Vault of the sourceforge site.
Before asking for formal review, your submission should be posted in the Boost files/vault. Please verify that your submission compiles and runs under at least two compilers. This flushes out obvious portability problems. If you don't have access to a second compiler, ask for help on the Boost mailing list.
Once a library author feels a submission (which presumably is now in the files/vault) has matured enough for formal review, the author sends a message requesting a formal review to the mailing list. Please use a subject in the form "Review Request: library" where library is replaced by the library name.
See Formal Review Process for details.
Formal Review schedules are posted on the mailing lists.
Once an accepted library is ready for inclusion on the Boost web site, the submitter is typically given Boost CVS write access, and expected to check-in and maintain the library in the CVS. Contact the moderators if you need write access or CVS use isn't possible for you.
If the boost.org web site doesn't already have your capsule biography and picture (optional, with not-too-serious pictures preferred), please send them to the Boost webmaster.. It is up to you as to whether or not the biography includes your email address or other contact information. The preferred picture format is .jpg, but other common formats are acceptable. The preferred image size is 500x375 but the webmaster has photo editing software and can do the image preparation if necessary.
Libraries are software; they lose their value over time if not maintained. Postings on the Boost developers or users mailing lists can alert you to potential maintenance needs; please plan to maintain your library over time. If you no longer can or wish to maintain your library, please post a message on the Boost developers mailing list and help someone else take over as the library maintainer.
Revised 26 November, 2003
© Copyright Beman Dawes 2000
Use, modification, and distribution are subject to the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at www.boost.org/LICENSE_1_0.txt)