Combining a couple replies...
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
On the other hand ....
1. Boost is about Excellency
Agree.
2. Nothing prevent usage of the library. It's accessible. And in this particular case I noticed several support request in users ML
While I agree that this is technically true, in the commercial world the politics matter -- and being an 'add-in' boost library makes it difficult to handle. I also believe it limits seriously the audience that will look at the library because my perception is that most boost users don't mess with the sandbox or CVS -- they use the releases and that's it.
3. As well as rejection may lead to discouraging further efforts, so could acceptance do. Could you expect any major issues to be resolved once library is delivered?
Yes, I expect major changes over time. Many libraries in boost have evolved significantly over time as users adopt and run into issues that cannot be fully anticipated in reviews. Iterator adaptors comes to mind as a library that, in theory, it's current state could have been fully analyzed up front. But, in fact, it took usage and a major refactoring, including interface changes, to get to the current design. Filesystem is another evolving library -- it solves real problems for many current users, but it doesn't do everything people want. Many of the changes are usage and user driven as Beman evolves the library interfaces. Some of the eventual changes are issues that were known at the time of the review. Just as another example, I think boost.threads needs a full do over, but that doesn't make it any less useful for those that can make use of the library as it is and boost would be lesser for it's absence.
4. In numerous case attempts to address any major issues results in complete new interface/design/implementation. Any users relying on accepted version would be disappointed. Also It most probable wont going to be reviewed as well (as it should be)
I agree. We certainly have known ways of handling this -- deprecating one interface over a couple releases, etc. As for reviews, I think if there is a truly motivated core of people the change then they will pursue and review the change more than the general boost list ever could. Much of this library future has to do with the nature of the author. One of my unstated evaluation criteria is the 'behavior' of the library author. The author must understand the domain, be ready to take criticism with grace, and move the work forward. If I didn't think Andreas is willing and up to this task I would have voted to reject...
5. I really-really with somebody spent more time with std::string on drawing board. Maybe we wouldn't have as much issues now. Even worse now everybody kinda required to accommodate it's existing interface and, for example, this #^*%ing traits template parameter is spreading like plague around numerous designs.
Perhaps, but I suspect there would be different tradeoffs with an alternative design. The other side is that if more time had been spent, it might have been like hash_map -- it would have just been absent. Where would C++ be if std::string wasn't part of the lib? Hard to imagine. In fact, 98% of the time when I'm writing a program I could care less about the traits template parameter and the other failings of std::string. BTW, I don't think I've seen a proposal that identifies and eliminates all the std::string issues -- I suspect that's because it's very difficult to balance the entire design space for strings in a single interface.
As a compromise for the situation like this we could introduce new section/area: "Unofficial libraries" where we could place those "complete/finished" submissions that did not passed a review (yet or again). Maybe some other staff.
Yeah, I've wondered about this approach myself. One of the great things boost does is 'normalize' the entire library development process. Where to put the headers, where to put the source, build system, documentation, regression testing, licensing, etc. Once a user or author has consumed this framework understanding the next library is fully focused on the library itself and not the surrounding mechanisms. The boost development framework is helpful, but it is currently 'tightly coupled' with review process. Interestingly, the Comprehensive Perl Archive Network (CPAN) has to handle all these same mechanisms (build, docs, etc), but it dispenses with the review. Anyone can upload a library the follows the conventions and it becomes available for use. In general, this makes me distrust everything I download from CPAN since there is a lack or quality control. However, there are many excellent packages -- many better than I could write from scratch. Sometimes a CPAN package might just serve as design inspiration for some custom code. Bottom line is CPAN is very useful if you are doing something in Perl. In fact, I suspect that Perl wouldn't be as widely used if not for CPAN. The closest C++ equivalent to CPAN is the 'boost sandbox'. It's good, but overall it doesn't have the searchability and other aspects that make CPAN useful -- wasn't designed to. C++ is also different from Perl in that portability to different compilers is still, unfortunately, a non-trivial issue. So practically speaking I have to download the sandbox library and run it against my compiler to even begin the evaluation of whether it will work for me -- a full Boost library has a regression test report. Anyway, while I think there are interesting directions that can be pursued to expand the contribution base via the sandbox, we would need significant work, in my opinion, to pursue these. And, in fact, perhaps we would want this to be a different organization from boost to make it clear that these aren't reviewed boost libraries.
David Abrahams wrote The serialization library is a beautiful example of how a rejection ended up being very positive for the library and for Boost. Whether or not that experience can be replicated is another question. It was certainly not easy for Robert.
Yes, serialization worked out and it's the only example of a rejected library getting accepted that I know. In most other cases, rejection meant that the author walked away. In a couple cases, walking away was expected because the conclusion of the review was that there wasn't a clear need for the library (FC++ for example). In other cases, though, the author just wasn't prepared to spend the time to try and make people happy (Fixed-Point Decimal). Jeff