| Home | Libraries | People | FAQ | More

# Boost Library Submission Process

This page describes the process of getting a library accepted by Boost. The process is still evolving, so if you have suggestions for improvement by all means post them on the mailing list.

See the Boost Library Requirements and Guidelines page for issues of content.

### Steps for getting a library accepted by Boost:

- Learn about Boost.
- Determine interest.
- Preliminary submission.
- Refinement.
- Formal Review.
- Web site posting.
- Lifecycle.

## Learn about Boost

Subscribe to the 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.

## Determine interest

Potential library submitters should use the 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 eGroups boost Files section (formerly called the " vault").

## Preliminary submission

If response to an initial query indicates interest, then post preliminary files in the Files section of the boost eGroups web site if you haven't already done so.

## Refinement

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.

## Formal Review

Before asking for formal review, 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 boost mailing list..

## Boost site posting

There are two ways that files are posted on the boost web site:

- Direct update of the boost CVS repository. This requires write access, and is primarily used for larger libraries, or for libraries maintained by very active boost developers.
- Packaging all files into submission file, and emailing it to the boost webmaster.

The submission file approach is as follows:

### Packaging

All of the files which make up the library should be combined and compressed into a single final 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.

### Final Submission file

The final submission file contains the material that will live on the boost.org web site. The closer the submission file mirrors the directory structure and format of the web site, the easier it is for the webmaster to integrate it into the web site.

The submission file for a library named foo should include these subdirectories, with the contents indicated:

> libs/foo

> - An introductory page named index.html or index.htm which looks like the initial page of other libraries. Rational is a model for single part libraries, Integer is a model for multi-part libraries.
> - The documentation page or pages, also in HTML format.
> - Source files implementing the library if it isn't entirely header based. The boost file type convention for source files is .cpp.
> - Test programs and data files if supplied.
> - If the library has a large number of subsidiary files which aren't linked to from the documentation pages, these subsidiary files can be combined into a single .zip file.

> boost

> - Public header files as described in the documentation for the library. The boost file type convention for header files is .hpp.

> boost/detail

> - Implementation header files not normally accessed by library users.

### Transmission

Submit via email to bdawes@acm.org. Attach the .zip submission file. In the email message, please include your email address, postal mail address, and telephone number, if boost.org doesn't already have them. Your addresses and phone number will not appear on the web site (unless you include them in your biography). Anonymous postings are not accepted.

### People pages

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 mailto:bdawes@acm.org. 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.

## Lifecycle

Libraries are software; they loose their value over time if not maintained. Details still hazy.

Revised 10 March, 2001