Robert, Rob, you are right that I could have rejected the library but I've preferred to accept it subject to a new review. The main reason is that I believe that this library would be useful for the C++ Boost community. It's not ready yet, but the features the library proposes are useful.
That's the way I read it.
Rob, the conditions will not be for conditional acceptance, but for having a new review. Sorry if this was not clear. with my sentence
Conditional acceptance (a new review is needed)
OK - I think that was widely misunderstood.
Unfortunately I've no time to do the report of the modifications that will be needed before the new review. The deadline for Oulu C++ standard committee is end of this month and I have some papers to finish.
Please, be patient,
No problem - I understand that it takes time to good job reviewing all the reviews. This is especially true when you don't really want to dismiss the submission outright but hope to see it transformed in some way. May main concern was it seemed accepted into boost subject to some conditions which were expected to be met - if not proforma. It seems that I got this wrong. I've objected in the past to the characterization of "conditionally accepted" in this context. Though I'm sympathetic to the idea that submission to boost should not be a gratuitously unpleasant process, I think attempting to "soften the blow" can lead to more frustration than less. I would also like to see us encourage pre-reviews on the incubator. I know this idea has not been successful, but I still think it's a good idea. I think it can be hugely helpful and motivating to library developers, improve quality of submissions and raise acceptance rate for library submissions. It can also wake up a library author to the fact that he's not really ready to submit - at much smaller cost in emotional frustration. For an example of how this can work, see the review in the safe numerics library. This one review made me re-think fundamental aspects of the submission in a way that otherwise wouldn't have happened. As I responded to the review and subsequent comments, I did a couple of things: a) I made the library simpler. It move toward a clearer and more unified concept as opposed to a disjoint bag of tricks. b) I had to make a better case about why I thought such a library was needed and worthwhile. The resulted in creating a bunch of tutorial examples illustrating the case where I thought such a library was necessary. Of course more examples made me think about the focus and feature set that was actually required. After this exchange - I worked another year on the library. If this library were to come up for review, one review is already done, in the queue and available for reference by other reviewers and/or review manager. I believe that the effort invested in this pre-review process will more than recovered in saving time in any final review and avoiding the dreaded "conditionally accepted" which is like your future ex-girlfriend telling you "I like you as friend". Also note that reviews posted in the incubator would be available to future users of the library and would be easily available to explain the rationale for all the decisions made - and all the features left out and all the arguments about this. It serves as an expanded FAQ. Robert Ramey