|
Boost : |
Subject: Re: [boost] [Review] Phoenix review starts today, September 21st
From: David Abrahams (dave_at_[hidden])
Date: 2008-09-30 08:42:02
on Mon Sep 29 2008, "Daniel Walker" <daniel.j.walker-AT-gmail.com> wrote:
> 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.
Once again, said better than I ever could. If I were to vote, I think I
would feel obliged to vote no despite my implicit trust in Joel's
abilities and sense of responsibility that tells me it'll probably turn
out alright. It's frustrating that we've managed to get ourselves in
this situation, but I don't think we should ever be reviewing code that
isn't what the author intends to release.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk