>3@
zZi8~?BysD3X%bWBbg}*TTzRLeIK5|mkGgkM-9BKsx#zz9?xEYRy9e)jD=vTGH>(Cc
zD*t!=JrMZyFVMNl5B$qJ{EYhnB9f1k!H?ia@(DqtfDl9|2nBt5RRHH!k>KoViWN?-
Jf_r)3e*v!!NJjtw
diff --git a/more/feature_model_diagrams.htm b/more/feature_model_diagrams.htm
deleted file mode 100644
index 2ca017a933..0000000000
--- a/more/feature_model_diagrams.htm
+++ /dev/null
@@ -1,112 +0,0 @@
-
-
-
-
-
-
-
-Feature Model Diagrams
-
-
-
-
-
-Feature Model Diagrams in text and HTML
-By Beman Dawes
-Introduction
-In their seminal book, Generative Programming, Czarnecki and Eisenecker (C&E))
-describe how to build feature models [C&E 4.4] consisting of a feature
-diagram plus semantic, rationale, and other attributes. Feature models are
-then used to drive design cycles which eventually lead to manual or automatic
-assembly of configurations.
-Feature models provide a language to describe the library variability that is
-often such an issue in boost.org discussions. The Whorf hypothesis that
-"Language shapes the way we think, and determines what we can think
-about" seems to apply. In discussion of library variability issues,
-we have been crippled by lack of a good language. With feature models we now
-have a language to carry on the dialog.
-The graphical feature diagrams presented by C&E are not in a suitable
-form for the email discussions boost.org depends upon. The hierarchical nature
-of feature diagrams can be represented by a simple text-based feature diagram
-language. A feature model can also take advantage of the hyperlinks
-inherent in HTML.
-
-The grammar for the feature diagram language is expressed in Extended
-Bakus-Naur Form; ::= represents productions, [...] represents options, {...}
-represents zero or more instances, and represents | alternatives.
-
- feature-model ::= concept-name details { feature }
- feature ::= feature-name [details]
- details ::= "(" feature-list ")" // required features
- | "[" feature-list "]" // optional features
- feature-list ::= element { "|" element } // one only
- | element { "+" element } // one or more
- | element { "," element } // all
- // [a+b] equivalent to [a,b]
- element ::= feature
- | details
- concept-name ::= name
- feature-name ::= name
-
-The usual lexical conventions apply. Names are case-insensitive and consist
-of a leading letter, followed by letters, digits, underscores or hyphens, with
-no spaces allowed.
-At least one instance of each name should be hyperlinked to the corresponding
-Feature Description.
-While the grammar is intended for written communication between people, it
-may also be trivially machine parsed for use by automatic tools.
-
-Descriptive information is associated with each concept or feature. According
-to [C&E 4.4.2] this includes:
-
- - Semantic descriptions.
- - Rationale.
- - Stakeholders and client programs.
- - Exemplar systems.
- - Constraints and default dependency rules.
- - Availability sites, binding sites, and binding mode.
- - Open/Closed attribute.
-
-What is a Feature?
-A feature [C&E 4.9.1] is "anything users or client programs might
-want to control about a concept. Thus, during feature modeling, we
-document no only functional features ... but also implementation features, ...,
-various optimizations, alternative implementation techniques, and so on."
-Example
-
- special-container ( organization,
- performance,
- interface ) // all required
- organization [ ordered + indexed ] // zero or more (4 configurations)
- indexed [ hash-function ] // zero or one (2 configurations)
- performance ( fast | small | balanced ) // exactly one (3 configurations)
- interface ( STL-style + cursor-style ) // one or more (3 configurations)
-
-There should be feature descriptions for some-container, organization,
-ordered, indexed, hash-function, performance, fast, small, balanced, interface,
-STL-style, and cursor-style
.
-The number of possible configurations is (2 + 2*2) * 3 * 3 = 54,
-assuming no constraints.
-There are equivalent representations. For example:
-
- special-container ( organization[ ordered+indexed[ hash-function ]],
- performance( fast|small|balanced ),
- interface( STL-style+cursor-style ) )
-
-References
-Krzysztof Czarnecki and Ulrich W. Eisenecker, Generative
-Programming, Addison-Wesley, 2000, ISBN 0-201-30977-7
-
-Revised 26 August 2004
-© Copyright Beman Dawes, 2000
-
-
- Distributed under the Boost Software License, Version 1.0. (See
- accompanying file LICENSE_1_0.txt or copy
- at http://www.boost.org/LICENSE_1_0.txt)
-
-
-
-
-
diff --git a/more/formal_review_process.htm b/more/formal_review_process.htm
deleted file mode 100644
index ca9ae11401..0000000000
--- a/more/formal_review_process.htm
+++ /dev/null
@@ -1,350 +0,0 @@
-
-
-
-
-
-
-
-
-
- Boost Formal Review Process
-
-
-
-
-
-
- Boost Formal Review Process
-
-
Before Requesting a Formal Review
-
Read and follow the Boost submission process. There are at
- least four steps a library author must take before a formal review is
- requested.
-
-
- Introduction
- What to include in Review Comments
- Results
- Notes for Review Managers
- Notes for Library Submitters
- Review Wizard
- Fast Track Reviews
-
-
-
- Proposed libraries are accepted into Boost only after undergoing a
- formal review, where Boost mailing list members comment on their evaluation
- of the library.
-
- The final "accept" or "reject" decision is made by the Review Manager, based on the review comments received
- from boost mailing list members.
-
- Boost mailing list members are encouraged to submit Formal Review
- comments:
-
-
-
- - Publicly on the mailing list.
-
- - Privately to the Review Manager.
-
-
-
- Private comments to a library submitter may be helpful to her or him,
- but won't help the Review Manager reach a decision, so the other forms are
- preferred.
-
- What to include in Review Comments
-
- Your comments may be brief or lengthy, but basically the Review Manager
- needs your evaluation of the library. If you identify problems along
- the way, please note if they are minor, serious, or showstoppers.
-
- The goal of a Boost library review is to improve the library through
- constructive criticism, and at the end a decision must be made: is the
- library good enough at this point to accept into Boost? If not, we hope to
- have provided enough constructive criticism for it to be improved and
- accepted at a later time. The Serialization library is a good example of how
- constructive criticism resulted in revisions resulting in an excellent
- library that was accepted in its second review.
-
- Here are some questions you might want to answer in your review:
-
-
- - What is your evaluation of the design?
-
- - What is your evaluation of the implementation?
-
- - What is your evaluation of the documentation?
-
- - What is your evaluation of the potential usefulness of the
- library?
-
- - Did you try to use the library? With what compiler? Did
- you have any problems?
-
- - How much effort did you put into your evaluation? A glance? A quick
- reading? In-depth study?
-
- - Are you knowledgeable about the problem domain?
-
-
- And finally, every review should answer this question:
-
-
- - Do you think the library should be accepted as a Boost library?
- Be sure to say this explicitly so that your other comments don't obscure
- your overall opinion.
-
-
- Many reviews include questions for library authors. Authors are
- interested in defending their library against your criticisms; otherwise
- they would not have brought their library up for review. If you don't get a
- response to your question quickly, be patient; if it takes too long or you
- don't get an answer you feel is sufficient, ask again or try to rephrase the
- question. Do remember that English is not the native language for many
- Boosters, and that can cause misunderstandings.
-
- E-mail is a poor communication medium, and even if messages rarely get lost
- in transmission, they often get drowned in the deluge of other messages.
- Don't assume that an unanswered message means you're being ignored. Given
- constructively, criticism will be taken better and have more positive
- effects, and you'll get the answers you want.
-
-
-
- At the conclusion of the comment period, the Review Manager will post a
- message to the mailing list saying if the library has been accepted or
- rejected. A rationale is also helpful, but its extent is up to the
- Review Manager. If there are suggestions, or conditions that must be met
- before final inclusion, they should be stated.
-
-
-
- Before a library can be scheduled for formal review, an active boost
- member not connected with the library submission must volunteer to be the
- "Review Manager" for the library.
-
- The Review Manager:
-
-
- - Checks the submission to make sure it really is complete enough to
- warrant formal review. See the Boost
- Library Requirements and Guidelines. If necessary, work with
- the submitter to verify the code compiles and runs correctly on several
- compilers and platforms.
-
- - Finalizes the schedule with the Review Wizard
- and the submitter .
-
- - Posts a notice of the review schedule on the regular boost mailing list, the
- boost-users
- mailing list, and the boost-announce mailing
- list.
-
-
- - The notice should include a brief description of the library and
- what it does, to let readers know if the library is one they are
- interested in reviewing.
-
- - If the library is known to fail with certain compilers, please
- mention them in the review notice so reviewers with those compilers
- won't waste time diagnosing known problems.
-
-
-
- - Inspects the Boost library
- catalogue for libraries which may interact with the new submission.
- These potential interactions should be pointed out in the review
- announcement, and the author(s) of these libraries should be privately
- notified and urged to participate in the review.
-
- - Urges people to do reviews if they aren't forthcoming.
-
- - Follows review discussions regarding the library, moderating or
- answering questions as needed.
-
- - Asks the review wizard for permission
- to extend the review schedule if it appears that too few reviews will
- be submitted during the review period.
-
- - Decides if there is consensus to accept the library, and if there
- are any conditions attached.
-
- - Decides if there is consensus to accept the library, and if there are
- any conditions attached.
-
- - Posts a notice of the review results on the
- regular boost mailing
- list, the boost-users mailing list,
- and the boost-announce mailing
- list.
-
-
- In other words, it is the Review Manager's responsibility to make sure
- the review process works smoothly.
-
-
-
- See Submission Process for a
- description of the steps a library developer goes through to get a library
- accepted by Boost.
-
- A proposed library should remain stable during the review period; it
- will just confuse and irritate reviewers if there are numerous
- changes. It is, however, useful to upload fixes for serious bugs
- right away, particularly those which prevent reviewers from fully
- evaluating the library. Post a notice of such fixes on the mailing
- list.
-
- Library improvements suggested by reviewers should normally be held
- until after the completion of review period. If the suggested changes
- might affect reviewer's judgments, post a notice of the pending change
- on the mailing list.
-
-
-
- The Review Wizard coordinates the formal review schedule:
-
-
- - Maintains a list of review manager volunteers, in the form of a
- queue, so that volunteers who least recently managed reviews become the
- prime candidates for upcoming reviews.
-
- - When a formal review is requested for a library:
-
- -
-
-
- - Assign a review manager and suggests a schedule, after checking
- (via private email) availability of the volunteers at the top of
- review manager queue.
-
- - Finalize the schedule, once the review manager verifies the
- library is actually ready for review.
-
- - Resolve schedule slips or other issues with review managers and
- submitters.
-
-
-
- - Monitors the general review process, and makes minor adjustments as
- needed, or queries the list about possible major adjustments.
-
- The role of Boost Review Wizard is currently played by John
- Phillips (phillips at mps dot ohio-state dot edu) and Ronald
- Garcia (garcia at cs dot indiana dot edu).
-
- Resolves questions from review managers and library submitters, who
- sometimes want a third opinion on questions such as "Should we extend the
- review period because ...?"
-
- Monitors the general review process, and makes minor adjustments as
- needed, or queries the list about possible major adjustments.
- The role of Boost Review Wizard is currently played by Tom Brinkman and Ronald Garcia (garcia at
- cs dot indiana dot edu).
-
- Revised
- 10 October, 2006
-
- To qualify for fast track review:
-
-
- - The component must be small.
-
- - The technique must be already in use in Boost libraries and the new
- component provides a common implementation.
-
- - A full Boost-conformant implementation is available in the
- sandbox.
-
- - The Review Wizard determines that the proposal qualifies for fast
- track review.
-
-
- Procedure:
-
-
- - The Boost Review Wizard posts a review announcement to the main Boost
- developer's list. The review period will normally last for 5 days. No two
- fast track reviews will run in parallel. Fast track reviews may run
- during full reviews, though generally this is to be avoided.
-
- - After the review period ends, the submitter will post a review
- summary containing proposed changes to the reviewed implementation.
-
- - The Review Wizard will accept or reject the proposed library and
- proposed changes.
-
- - After applying the proposed changes, the component is checked into
- CVS like any other library.
-
-
-
-
- Revised
- 15
- October, 2003
-
- © Copyright Beman Dawes 2000
-
- Distributed under the Boost Software License, Version 1.0. (See
- accompanying file LICENSE_1_0.txt or copy
- at http://www.boost.org/LICENSE_1_0.txt)
-
-
diff --git a/more/formal_review_schedule.html b/more/formal_review_schedule.html
deleted file mode 100644
index d0409aba16..0000000000
--- a/more/formal_review_schedule.html
+++ /dev/null
@@ -1,916 +0,0 @@
-
-
-
-
-
-
-Formal Review Schedule
-
-
-
-
-
-Formal Review Schedule
-Reviews are usually scheduled on a first-come-first-served basis, and
-normally last ten days. See Formal
-Review Process for more information.
-In addition to
-upcoming reviews, the schedule includes recent reviews already completed; that helps
-track review manager assignments and libraries reviewed but not yet posted on
-the web site. There is often a lag between acceptance and site posting as
-authors address issues raised in the formal review.
-
-
-
-
- Submission |
- Submitter |
- Link |
- Review
- Manager |
- Review
- Dates |
-
-
-
- Finite State Machines |
- Andrey Semashev |
-
- Boost Sandbox Vault |
- Martin Vuille |
- - |
-
-
-
- Floating Point Utilities |
- Johan Råde |
-
- Boost Sandbox Vault |
- Needed |
- - |
-
-
-
- Switch |
- Steven Watanabe |
-
- Boost Sandbox Vault |
- Stejpan Rajko |
- January 5, 2008 - January 9, 2008 |
-
-
-
- Property Map (fast-track) |
- Andrew Sutton |
-
- Boost Sandbox |
- Jeremy Siek |
- - |
-
-
-
- Graph (fast-track) |
- Andrew Sutton |
-
- Boost Sandbox |
- Jeremy Siek |
- - |
-
-
-
- Forward (fast-track) |
- Tobias Schwinger |
-
- Boost Sandbox Vault |
- John Torjo |
- January 14, 2008 - January 18, 2008 |
-
-
-
- Singleton (fast-track) |
- Tobias Schwinger |
-
- Boost Sandbox Vault |
- John Torjo |
- December 3, 2007 - December 7, 2007 |
-
-
-
- Factory (fast-track) |
- Tobias Schwinger |
-
- Boost Sandbox Vault |
- John Torjo |
- December 17, 2007 - December 21, 2007 |
-
-
-
- Lexer |
- Ben Hanson |
-
- Boost Sandbox Vault |
- Hartmut Kaiser |
- - |
-
-
-
- Thread-Safe Signals |
- Frank Hess |
-
- Boost Sandbox Vault |
- Needed |
- - |
-
-
-
- Logging |
- John Torjo |
- http://torjo.com/log2/ |
- Gennadiy Rozental |
- February 4, 2008 - February 13, 2008 |
-
-
-
- Flyweight |
- Joaquín Mª López Muñoz |
-
- Boost Sandbox Vault |
- Ion Gaztañaga |
- January 21, 2008 - January 30, 2008 |
-
-
-
- Unordered Containers |
- Daniel James |
- Boost Sandbox Vault |
- Ion Gaztañaga |
- December 7, 2007 - December 16, 2007 |
-
-
-
- Boost.Range (Update) |
- Neil Groves |
-
- Boost Sandbox Vault |
- Needed |
- - |
-
-
-
-
-
-
-Past Review Results and Milestones
-
-
- Submission |
- Submitter |
- Review
- Manager |
- Review
- Dates |
- Result |
-
-
-
- Review Wizard Status Report |
- |
- Ronald Garcia |
- 2007 November 16 |
- Report |
-
-
-
- Exception |
- Emil Dotchevski |
- Tobias Schwinger |
- September 27, 2007 - October 7, 2007 |
-
- Accepted |
-
-
-
- Review Wizard Status Report |
- |
- Ronald Garcia |
- 2007 September 14 |
- Report |
-
-
-
- Scope Exit |
- Alexander Nasonov |
- Jody Hagins |
- August 13, 2007 - August 22, 2007- |
-
- Pending |
-
-
-
- Time Series |
- Eric Niebler |
- John R. Phillips |
- July 30, 2007 - August 13, 2007 |
-
- Accepted |
-
-
-
- Boost 1.34.1 Released |
- |
- Thomas Witt |
- July 24, 2007 |
-
- Notes |
-
-
-
- Boost 1.34.0 Released |
- |
- Thomas Witt |
- May 12, 2007 |
-
- Notes |
-
-
-
- Globally Unique Identifier |
- Andy Tompkins |
- Hartmut Kaiser |
- April 30, 2007 - May 10, 2007 |
-
- Accepted Provisionally |
-
-
-
- Math Toolkit |
- John Maddock |
- Matthias Schabel |
- April 11, 2007 - April 27, 2007 |
-
- Accepted -- Added to SVN |
-
-
-
-
- Quantitative Units |
- Matthias Schabel |
- John R. Phillips |
- March 26, 2007 - April 4, 2007 |
-
- Accepted |
-
-
-
- Intrusive Containers |
- Ion Gaztañaga |
- Joaquín Mª López Muñoz |
- March 12, 2007 - March 21, 2007 |
-
- Accepted -- Added to CVS |
-
-
-
-
- Bimap |
- Matias Capeletto |
- Ion Gaztañaga |
- February 15 2007- March 2, 2007 |
-
- Accepted -- Added to CVS |
-
-
-
- Accumulators |
- Eric Niebler |
- John R. Phillips |
- January 29, 2007 - February 7, 2007 |
-
- Accepted |
-
-
-
-
- Function Types (Re-review) |
- Tobias Schwinger |
- Tom Brinkman |
- 2006 November 6 - 2006 November 17 |
-
- Accepted -- Added to CVS |
-
-
-
- Generic Image Library |
- Lubomir Bourdev |
- Tom Brinkman |
- 2006 October 5 - 2006 October 25 |
-
- Accepted -- Added to CVS |
-
-
-
- Message Passing |
- Doug Gregor |
- Jeremy Siek |
- 2006 September 6 - 2006 September 15 |
-
- Accepted -- Added to CVS |
-
-
-
- Physical Quantities System |
- Andy Little |
- Fred Bertsch |
- 2006 May 31 - 2006 June 9 |
-
- Rejected |
-
-
-
- Pimpl Pointer |
- Asger Mangaard |
- Rene Rivera |
- 2006 May 15 - 2006 May 24 |
-
- Rejected |
-
-
-
- Fusion |
- Joel de Guzman |
- Ronald Garcia |
- 2006 May 1 - 2006 May 10 |
-
- Accepted -- Added to CVS |
-
-
-
- Property Tree |
- Marcin Kalicinski |
- Thorsten Ottosen |
- 2006 April 18 - 2006 April 30 |
-
- Accepted -- Added to CVS |
-
-
-
- Promotion Traits (fast-track) |
- Alexander Nasonov |
- Tobias Schwinger |
- 2006 April 1 - 2006 April 9 |
-
- Accepted -- Added to CVS |
-
-
-
- Review Wizard Status Report |
- |
- Tom Brinkman |
- 2006 March 30 |
- Report |
-
-
-
- Shmem (now Interprocess) |
- Ion Gaztañaga |
- Fred Bertsch |
- 2006 February 6 - 2006 February 15 |
-
- Accepted -- Added to CVS |
-
-
-
- Fixed Strings |
- Reece Dunn |
- Harmut Kaiser |
- 2006 January 19 - 2006 February 5 |
-
- Rejected |
-
-
-
- Review Wizard Status Report |
- |
- Ronald Garcia |
- 2006 January 19 |
- Report |
-
-
-
- asio |
- Christopher Kohlhoff |
- Jeff Garland |
- 2005 December 10 - 2005 December 30 |
-
- Accepted -- Added to CVS |
-
-
-
- Boost 1.33.1 Released |
- |
- Doug Gregor |
- 2005 December 5 |
-
- Notes |
-
-
-
- Review Wizard Status Report |
- |
- Ronald Garcia |
- 2005 December 1 |
-
- Report |
-
-
-
- Logging Library |
- John Torjo |
- Hartmut Kaiser |
- 2005 November 7 - 2005 November 16th |
-
- Rejected |
-
-
-
- Boost 1.33.1 Beta Released |
- |
- Doug Gregor |
- 2005 November 9 |
-
- Notes |
-
-
-
- binary_int |
- Scott Schurr and Matt Calabrese |
- Pavel Vozenilek |
- 2005 October 13 - 2005 October 20 |
-
- Accepted -- not yet added. |
-
-
-
- TR1 |
- John Maddock |
- Beman Dawes |
- 2005 September 24 - 2005 October 5 |
- Accepted -- Added in 1.34 |
-
-
-
- Xpressive |
- Eric Niebler |
- Thomas Witt |
- 2005 September 8 - 2005 September 18 |
- Accepted -- Added in 1.34 |
-
-
-
- Boost 1.33.0 Released |
- |
- Doug Gregor |
- 17 August 2005 |
-
- Notes |
-
-
-
- Function Types |
- Tobias Schwinger |
- John Maddock |
- 2005-Jun-6 to 2005-June-16 |
-
- Accepted Provisionally |
-
-
-
- Typeof |
- Arkadiy Vertleyb and Peder Holt |
- Andy Little |
- 2005 May 20 - 2005 May 30 |
- Accepted -- Added in 1.34 |
-
-
-
- Singleton |
- Jason Hise |
- Pavel Vozenilek |
- 2005 May 5 - 2005 May 15 |
-
- Rejected |
-
-
-
- FOREACH Macro |
- Eric Niebler |
- Gennadiy Rozental |
- 2005 April 25 - 2005 May 1 |
- Accepted -- Added in 1.34 |
-
-
-
- Hash |
- Daniel James |
- Thorsten Ottosen |
- 2005 Mar 21 - 2005 March 12 |
- Accepted -- Added in 1.33 |
-
-
-
- State Chart |
- Andreas Huber |
- Pavel Vozenilek |
- 2005 Feb 23 - 2005 March 9 |
- Accepted -- Added in 1.34 |
-
-
- Wave |
- Hartmut Kaiser |
- Tom Brinkman |
- 2005 Feb 7 - 2005 Feb 20 |
- Accepted -- Added in 1.33 |
-
-
- Pointer Containers |
- Thorsten Ottosen |
- Pavol Droba |
- 2004 Sept 26 - Oct 5 |
- Accepted -- Added in 1.33 |
-
-
- Named Params |
- David Abrahams & Daniel Wallin |
- Doug Gregor |
- 2004 Nov 1 - 2004 Nov 20 |
- Accepted -- Added in 1.33 |
-
-
- Output Formatters |
- Reece Dunn |
- John Torjo |
- 2004 Sept 11 - Sept 25 |
-
- Rejected |
-
-
- Iostreams |
- Jonathan Turkanis |
- Jeff Garland |
- 2004 Aug 28 - Sep 11 |
- Accepted -- Added in 1.33 |
-
-
- More IO |
- Daryle Walker |
- Tom Brinkman |
- 2004 Aug 21 - 28 |
- Rejected |
-
-
- Tribool |
- Douglas Gregor |
- Thomas Witt |
- 2004 May 19-29 |
- Accepted -- Added in 1.32 |
-
-
- Assignment |
- Thorsten Ottosen |
- Tom Brinkman |
- 2004 Apr 1 - 11 |
- Accepted -- Added in 1.32 |
-
-
- Serialization (re-review) |
- Robert Ramey |
- Jeff Garland |
- 2004 Apr 13 - 26 |
- Accepted -- Added in 1.32 |
-
-
- Container Traits (now Range) |
- Thorsten Ottosen |
- Hartmut Kaiser |
- 2004 Apr 28 - May 7 |
- Accepted -- Added in 1.32 |
-
-
- Indexed Set (now MultiIndex) |
- Joaquín Mª López Muñoz |
- Pavel Vozenilek |
- 2004 Mar 20 - 30 |
-
- Accepted -- Added in 1.32 |
-
-
- Circular Buffer |
- Jan Gaspar |
- Pavel Vozenilek |
- 2004 Mar 5 - 15 |
- Accepted -- Added to CVS |
-
-
- enable_if |
- Jaakko Järvi & Jeremiah Willcock & Andrew Lumsdaine |
- (fasttrack) |
- Dec 2003 |
- Accepted -- added in 1.31 |
-
-
- FC++ |
- Brian McNamara & Yannis Smaragdakis |
- Mat Marcus |
- 2004 Feb 14 - Mar 1 |
- Rejected |
-
-
- Numeric Conversions Library |
- Fernando Cacciola |
- Thorsten Ottosen |
- 8 - 22 Dec 2003 |
- Accepted -- added in 1.32 |
-
-
- String Algorithm Library |
- Pavol Droba |
- Thorsten Ottosen |
- 17 - 30 Oct 2003 |
- Accepted -- added in 1.32 |
-
-
- Shifted Pointer |
- Philippe A. Bouchard |
- Doug Gregor |
- 24 - 30 Sep 2003 |
- Rejected |
-
-
- Fixed-Point Decimal |
- Bill Seymour |
- Jens Maurer |
- 11 - 21 Jul 2003 |
- Rejected |
-
-
- Math Constants |
- Paul A. Bristow |
- Jaap Suter |
- 06 - 15 Jun 2003 |
- Rejected |
-
-
- Command Line & Config |
- Vladimir Prus |
- Aleksey Gurtovoy |
- 21 May - 03 Jun 2003 |
- Accepted -- added in 1.32 |
-
-
- I/O Manipulators and Adaptors |
- Daryle Walker |
- Ed Brey |
- 27 Feb - 11 Mar 2003 |
- - |
-
-
- Variant |
- Eric Friedman & Itay Maman |
- Jeff Garland |
- 16 - 25 Feb 2003 |
- Accepted -- added in 1.31 |
-
-
- Optional |
- Fernando Cacciola |
- Douglas Gregor |
- 09 - 18 Dec 2002 |
- Accepted -- added in 1.30 |
-
-
- Serialization |
- Robert Ramey |
- Dave Abrahams |
- 02 - 11 Nov 2002 |
- Rejected |
-
-
- Spirit |
- Joel de Guzman |
- John Maddock |
- 11 - 20 Oct 2002 |
- Accepted -- added in 1.30 |
-
-
- Minmax |
- Hervé Bronnimann |
- Thomas Witt |
- 28 Sep - 07 Oct 2002 |
- Accepted -- added in 1.32 |
-
-
- Filesystem |
- Beman Dawes |
- William Kempf |
- 14 - 23 Sep 2002 |
- Accepted -- added in 1.30 |
-
-
- Interval Arithmetic Library |
- Hervé Bronnimann & Guillaume Melquiond & Sylvain Pion |
- Beman Dawes |
- 31 Aug - 09 Sep 2002 |
- Accepted -- added in 1.30 |
-
-
- Template Meta Programming Library MPL |
- Aleksey Gurtovoy |
- Douglas Gregor |
- 15 - 29 Jul 2002 |
- Accepted -- added in 1.30 |
-
-
- uBLAS |
- Joerg Walter & Mathias Koch |
- Ed Brey |
- 21 Jun - 01 Jul 2002 |
- Accepted -- added in 1.29 |
-
-
- Dynamic Bitset |
- Chuck Alison & Jeremy Siek |
- Mat Marcus |
- 08 - 17 Jun 2002 |
- Accepted -- added in 1.29 |
-
-
- Date / Time |
- Jeff Garland |
- Darin Adler |
- 15 - 24 Apr 2002 |
- Accepted -- added in 1.29 |
-
-
- Lambda |
- Jaakko Järvi & Gary Powell |
- Aleksey Gurtovoy |
- 08 - 20 Mar 2002 |
- Accepted and added |
-
-
- Signals |
- Douglas Gregor |
- William Kempf |
- 18 - 27 Feb 2002 |
- Accepted -- added in 1.29 |
-
-
- I/O State Saver |
- Daryle Walker |
- Beman Dawes |
- 06 - 16 Feb 2002 |
- Accepted and added |
-
-
- printf-like formatting for iostreams |
- Samuel Krempp |
- Jens Maurer |
- 13 - 23 Jan 2002 |
- Accepted -- added in 1.29 |
-
-
- Multi-array |
- Ron Garcia |
- John Maddock |
- 02 - 12 Jan 2002 |
- Accepted -- added in 1.29 |
-
-
- Unit Test Library |
- Gennadiy Rozental |
- Jeremy Siek |
- 01 - 13 Dec 2001 |
- Accepted and added |
-
-
- GCD Library plus integer additions |
- Daryle Walker |
- Dave Abrahams |
- 17 - 26 Sep 2001 |
- - |
-
-
- Thread Library |
- Bill Kempf |
- Ed Brey |
- Aug 30 - Sep 8 |
- Accepted and added |
-
-
- Config System |
- John Maddock |
- Doug Gregor |
- Aug 20 - 29 |
- Accepted and added |
-
-
- Bind Library |
- Peter Dimov |
- Darin Adler |
- Aug 10 - 19 |
- Accepted and added |
-
-
- Base from Member Library |
- Daryle Walker |
- Beman Dawes |
- Jul 30 - Aug 9 |
- - |
-
-
- Coding Guidelines |
- Dave Abrahams |
- Aleksey Gurtovoy |
- Jul 20 - 29 |
- - |
-
-
- Preprocessor Library |
- Vesa Karvonen |
- Jeremy Siek |
- Jun 28 - Jul 9 |
- Accepted and added |
-
-
- Tuples Library |
- Jaakko Järvi |
- Beman Dawes |
- Jun 17 - 26 |
- Accepted and added |
-
-
- Function Library |
- Doug Gregor |
- John Maddock |
- Jun 6 - 16 |
- Accepted and added |
-
-
- Tokenizer |
- John Bandela |
- Doug Gregor |
- May 28 - Jun 6 |
- Accepted and added |
-
-
- Special Functions |
- Hubert Holin |
- Jens Maurer |
- May 18 - 27 |
- Accepted and added |
-
-
-
-We try to rotate the task of Review Manager between many experienced Boost
-members, both to ensure fairness, and to spread the workload. If you would
-like to volunteer to become a review manager, please contact
-John Phillips (phillips at mps dot ohio-state dot edu) or Ronald
- Garcia (garcia at cs dot indiana dot edu).
-
-
-Revised
-15 Apr 2005
-
-Copyright Beman Dawes, Tom Brinkman, Jeff Garland 2001 - 2005
-Distributed under the Boost Software License, Version 1.0. (See
-accompanying file LICENSE_1_0.txt or copy
-at http://www.boost.org/LICENSE_1_0.txt)
-
-
-
-
-
diff --git a/more/getting_started/unix-variants.html b/more/getting_started/unix-variants.html
index 0f90a525f3..edf1c58917 100644
--- a/more/getting_started/unix-variants.html
+++ b/more/getting_started/unix-variants.html
@@ -716,11 +716,10 @@ mailing list