Niall Douglas wrote:
Glen Fernandes wrote:
Isn't "I don't understand the point of this library" a valid reason for rejection?
In itself, no I don't think so. There are at least ten libraries in Boost I have no understanding of the point of
If almost nobody the understands point of a proposed library to the extent that almost nobody recommend its acceptance: I would think that it isn't unjustly rejected. I believe niche use case libraries have a place in Boost. I suspect, though, that an asynchronous file I/O library falls into the category of something that most people want in Boost. I haven't figured out entirely where the disconnect is. It seems like you're saying "This is the async file I/O library that you need; not the async file I/O library that you want." You also say that only a tiny fraction of developers have those needs. Are any of them going to be reviewing this library?
Can you explain what is not straightforward more precisely please?
Sure. With regards to the examples: - Be more concise, - Have less standard out statements, - Have less comments, - Have no conditional compilation * BOOST_AFIO_USE_LEGACY_FILESYSTEM_SEMANTICS? How can parts of AFIO be legacy? * #if 0? In an example? * No platform specifics The other advice I have is that you may want to omit a comment like "This section was not finished in time for the beginning of the Boost peer review due a hard drive failure induced by the testing of AFIO-based key-value stores in this workshop tutorial (sigh!)" in the documentation. You don't want prospective reviewers to wonder if they should back up their hard drive before trying AFIO. :-) Glen -- View this message in context: http://boost.2283326.n4.nabble.com/afio-AFIO-review-postponed-till-Monday-tp... Sent from the Boost - Dev mailing list archive at Nabble.com.