First of all, I would like to thank everyone who participated in the review process, and Klemens for submitting the library. In total, we received 9 reviews: 3 ACCEPT, 3 CONDITIONALLY ACCEPT, and 3 REJECT. The individual reviews are as follows: Barend Gehrels: ACCEPT [1] Ruben Perez: REJECT [2] Scott Bailey: ACCEPT [3] Mungo Gill: CONDITIONALLY ACCEPT [4] Amlal El Mahrouss: ACCEPT [5] Harold Bott: CONDITIONALLY ACCEPT [6] Darryl Green: CONDITIONALLY ACCEPT [7] Andrzej Krzemienski: REJECT [8] Maximilian Riemensberger: REJECT [9] After carefully examining all reviews, going through the mailing list discussions, and consulting with Ruben Perez (author of Boost.MySQL) and Klemens, I have decided to REJECT the library due to critical flaws in the API and insufficient documentation. I strongly encourage the author to make another submission after addressing the issues listed below: - connection ownership ambiguity: A connection object can currently be constructed in two forms, owning and non-owning, which makes reasoning about it difficult. It was suggested on the mailing list to introduce a connection_ref type, which not only resolves this problem but also makes it easier for a user to wrap an existing sqlite3* (acquired from another library or C API) and benefit from the type safety provided by this library. - resultset ownership ambiguity: A resultset can either own an sqlite3_stmt or act as a non-owning reference to an existing sqlite3_stmt, providing only an access interface. This dual behavior makes reasoning about ownership difficult and allows multiple resultset objects to reference the same sqlite3_stmt, giving the false impression that they exist independently of the main statement object. Further exploration is needed to determine the right API. One suggestion from the mailing list is to remove the resultset type entirely and merge its functionality into the statement type, with a non-owning view/range type that can be used for iterating without having to pass the statement object around. - Wrong usage of cstring_ref (minor): As noted in the reviews, field::get_text could return a core::string_view instead of a cstring_ref, since SQLite already provides an API for determining the length of a column. - CI and test coverage: Currently, the CI supports only a limited set of platforms. It should, at a minimum, build and test the project on Linux, Windows, and macOS using Clang, GCC, and MSVC, with a matrix of configurations (RTTI on/off, exceptions on/off, shared/static). It should also include sanitizer builds and coverage reports. I would recommend that the author use the coverage report results to improve the tests, as the current tests do not appear to cover all interfaces. - Build scripts: The Jamfile should allow using libsqlite3 even when it is not installed system-wide and exists only in package manager paths, such as vcpkg. The necessary Jamfile for locating libsqlite3 should likely be added to the Boost.Build repository. - Examples: The existing examples cover advanced usage, such as SQLite virtual tables, but lack clear and simple use cases. I would recommend that the author focus on the most frequently used APIs and provide examples that quickly convey the knowledge needed to use the library for simple tasks. - Documentation: Currently, there is very little documentation around important types such as connection, statement, resultset, row, field, and value. I would recommend that the author provide proper documentation and usage examples for each type, and place extra emphasis on the quick-start section, as it is likely the part most users will read. - Real-world users: Considering the nature of this library, I would recommend that the author seek feedback from real-world users before submitting it again, as many design flaws in the libraries of this kind only become apparent through practical use. Without such feedback, it is difficult to anticipate usage patterns and design interfaces accordingly. Additionally, receiving reviews from users who have successfully used the library in their applications provides extra confidence to the release manager regarding the library's future success. [1] https://lists.boost.org/archives/list/boost@lists.boost.org/message/MGOXOV6S... [2] https://lists.boost.org/archives/list/boost@lists.boost.org/message/57ZZ7IIW... [3] https://lists.boost.org/archives/list/boost@lists.boost.org/message/BD3OQOWO... [4] https://lists.boost.org/archives/list/boost@lists.boost.org/message/O477WE5S... [5] https://lists.boost.org/archives/list/boost@lists.boost.org/message/BUL75BOX... [6] https://lists.boost.org/archives/list/boost@lists.boost.org/message/CS3FT3E7... [7] https://lists.boost.org/archives/list/boost@lists.boost.org/message/VKZMFA65... [8] https://lists.boost.org/archives/list/boost@lists.boost.org/message/DIP5GYYP... [9] https://lists.boost.org/archives/list/boost@lists.boost.org/message/TVXSK4DP... Best regards, Mohammad Nejati Review Manager for the proposed Boost.SQLite