Re: [boost] Re: FSM Review

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-03-12 11:31:06

Combining a couple replies...

> "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> 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