On Sun, Sep 28, 2008 at 4:13 AM, dan marsden <danmarsden@yahoo.co.uk> 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