On 18 Mar 2015 at 9:41, Pete Bartlett wrote:
This release took far longer than I originally intended mainly due to the extensive debugging of weird filing system races, and for six weeks now I've been working till 5am every night after my day job. I cannot tell you how glad I am to see this release out!
You are obviously very proud of this library and I believe rightly so. You've worked hard on it and in terms of things like soak testing it probably sets a new high watermark for Boost libraries.
I'm proud of what I've been able to do with the very limited resources available to me, but I feel not especially proud of shipping a library which isn't well tested in absolute terms. For example, almost all the testing is functional rather than unit testing (lack of time to write more), plus the soak tests run for minutes instead of the 6 or 24 hours I'd much prefer and on only quad core hardware with local drives rather than the 16-32 core distributed over Samba/NFS network shares that it should be. I'm also not happy with the testing of the (too) many build options, the lack of testing of std::bad_alloc correctness (right now I claim exception safety except for bad_alloc), and there is no testing of localised resource leaks, only global testing. Ok, so like most Boost maintainers I see all that I failed to do before any of the achievements. Still, it could be a lot better than it is, and a bug in AFIO means data loss for users. In the end, we all have day jobs and families.
You're also a highly active member of this community. So why is the library always "proposed".... When is there going to be a review? :)
When a review manager volunteers themselves! Antony nearly did a few months ago, but this release was in progress and at that time I had no ABI nor API versioning in AFIO, so I could not propose an even semi-stable API at that time. In the v1.3 release, both ABI and API are versioned and there is a unit test which compiles two intentionally dimorphic and ABI incompatible copies of AFIO into the same translation unit and runs both sets of unit tests for each to make sure they don't collide. They don't, so I am now sure v1.3 of AFIO can coexist without issue with v1.4 of AFIO or any other version. So I now have no objections, and furthermore no major work will be done to AFIO until after CppCon in September. Still, asynchronous file i/o and race free filesystem is an extremely niche use case. I am not aware of anyone who uses AFIO in their code. That has surely to count against the wisdom of including it into Boost official as without a user base, who can really say if a design or implementation is any good during review? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/