* What is your evaluation of the design?

Good analysis of the target domain, clean separation of concerns. However the flexibility of this is throwing too much burden on the user and has made the barrier to entry too high. IMO, simple usages can be made simpler without sacrificing much of extendability.

* What is your evaluation of the implementation?

Didn't look much into it

* What is your evaluation of the documentation?

Too complex and can turn away many potential users. Too many times terms are introduced without being clearly explained. It lacks a natural flow and appears chunky. Maybe the choice of doxygen to partly to blame since it encourages such style. Maybe it is great for "advanced" section, but introduction could benefit from old-fashioned sequential writing.

* What is your evaluation of the potential usefulness of the library?

Significant. Every project I encountered needed a logging facility, and this library is open enough to actually cover significant portion of uses with some extending.

* Did you try to use the library? With what compiler? Did you have any problems?

In a simple test project with VC 7.1, trying to re-create functionality provided by v1 of the logging library, namely the ability to create a hierarchy of loggers, such as "system.network.tcpip" or "system.storage.db", and configure different outputs dynamically, based on modules and levels, at run time. * Single threaded configuration not supported, fails with somewhat cryptic message in cache_before_init:43 * a list of dependencies on other boost libs in the docs could be helpful * could not figure out which tradeoffs that scenario::usage is supposed to resolve. * decoupling the tags example from scenario::usage turned out not trivial. * hit some sort of appender vs prepender conflict while playing with combining named_spacer with tags formatter. * didn't like the DEFINE_LOG_XXX /DECLARE_LOG_XXX macros and would prefer to have the code behind them visible.

* How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?

About 6 hours overall. Within that time frame, I have been unable to replicate v1 functionality, but it appears that the design does not precludes it. However, I'd strongly prefer that functionality to be available out of the box.

* Are you knowledgeable about the problem domain?

Reasonably so: I've evaluated several logging libraries, developed and deployed my own library in past. Also had experience integrating boost::logging v1 library into ~100KLOC project.

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.

Yes, with some improvements to documentation and ease-of-use, I believe it will make a valuable addition to boost. While I agree with previous reviewers about quality requirements for boost logging library, my opinion is that "yes, with improvements" vote will better serve that purpose, in encouraging John not to go for another 2-year redesign cycle. Best regards, Vadim