|
Home | Libraries | People | FAQ | More |
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.
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.
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").
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.
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.
[The Formal Review procedure is new as of 9 May, 2000, and will be refined as experience dictates.]
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.
Reviews are scheduled so that:
Before a library can be scheduled for review, an active boost member not connected with the library submission must volunteer to be the "Review Manager" for that library. The review manager decides on the schedule, posts a notice when the review period starts, how long it lasts, and how boost members can contribute their comments. The review manager collects comments, chairs any discussions, and then when the review period is over, decides if there is enough consensus to accept the library.
See Formal Review Process for details.
Members only can see Formal Review Schedule for the current library review schedule.
[The plan is that the first several reviews will be managed by long-time boost contributors who will be encouraged to experiment with the review process. Presumably, successful processes will evolve over time and can then be documented.]
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.
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 or Utility are models 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.
Submit via email to webmaster@boost.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.
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:webmaster@boost.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.
Libraries are software; they loose their value over time if not maintained. Details still hazy.
Revised 19 June, 2000