|
Boost : |
Subject: Re: [boost] [Review] Phoenix review starts today, September 21st
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-09-29 11:19:17
On Sun, Sep 28, 2008 at 4:13 AM, dan marsden <danmarsden_at_[hidden]> wrote:
> Daniel Walker wrote:
> <snip>
>>Of course not. :-) But going in-depth into V2's implementation is not
>>the same as going in-depth into V3. The design may be the same, but
>>simple diffing and greping shows the implementations are not. And
>>that's to be expected. As I understand, whole components were gutted
>>and replaced with Proto, which is a good thing. So let's continue that
>>effort and spend our energy on V3 and not look back!
>>
>>Now, how that relates to the review formalities and the fact that
>>apparently V2 is under review, I am not sure. As far as I can tell,
>>all the reviews thus far have assumed the V2 implementation. I would
>>suggest withdrawing V2 from consideration (leaving it as is in
>>Boost.Spirit), finishing V3 (which becomes the new Boost.Lambda), and
>>then resubmitting for review, but I'm no expert on this process.
>>
> It is my understanding that Boost authors retain the "rights" to modify and
> upgrade their libraries once accepted, both in terms of implementation
> and interface changes. Boost.Xpressive has seen many changes iirc,
> including the sorts of changes that we're discussing (reimplementing
> in terms of proto + I believe some smaller interface changes). Many
> other libraries have similar history. If the authors of these libraries
> had stated their development plans, in advance of review, should they
> have been rejected until they were "finished"? Joel has been very open
> in stating his future plans, but what he plans has happened many times
> before to accepted libraries.
>
> Obviously the rather fluid state of the libraries does muddy the purpose
> of the review. I'd suggest we review libraries as is, answer all the usual
> questions about interface, quality of implementation, docs etc. There seems
> to be some implicit assumption that the author will act in the spirit of
> Boost, and reimplement + extend to the same level of quality as seen in
> the review. I think Joels track record in this area speaks for itself.
>
> On your other comment about Phoenix2 remaining under Spirit if it were not
> to be accepted, that is obviously true, but at some employers/organizations
> passing the review process and being an official part of a Boost release is
> a prerequisite to using a library.
This is an important point.
The reason peer-reviewed software (or peer-reviewed science and
engineering in general) is valued by employers, organizations, etc. is
that it mitigates risk. Rather than merely trusting the authors, you
can additionally rely on the authors' peers. Interface changes
obviously introduce risk, but certainly large implementation changes
do as well. If Boost releases a library with large amounts of code
that have not been reviewed, then you can't really call it a
peer-reviewed library. I understand that on occasion this has happened
in the past when authors have made significant changes/upgrades
without a review. However, I believe we should not let that happen in
the case of the Boost.Lambda upgrade, i.e. Phoenix V3 release.
Also, my criticisms during this review period are not personal in
nature. If we were voting for the Phoenix authors, I would vote a
resounding yes, as they have my every confidence and admiration.
However, we are not reviewing authors, we are reviewing a library. So
I have to put my engineering hat on and demand evidence. Show me the
code! :-)
Finally, on a personal note, I myself have been guilty of promising a
roadmap, having it "reviewed," and then not delivering. I'm sure the
authors of Phoenix would never repeat my mistake, but my own personal
failure only reinforce for me the importance of basing a review on
actual code. V2 is not the code the authors intend to release. So, I
believe it would be beneficial to leave V2 as it is, focus the list's
energy on V3, finish it, review it, and ship it.
Daniel Walker
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk