Re: [boost] [Review] Phoenix review starts today, September 21st
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. Cheers Dan
on Sun Sep 28 2008, dan marsden <danmarsden-AT-yahoo.co.uk> wrote:
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.
I think one difference here may be that Joel already knows he has interface-breaking changes planned (if that's not actually the case, I apologize). Several libraries have had interface-breaking changes after acceptance, but AFAIK these were not anticipated at the time of the review. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Sun Sep 28 2008, dan marsden <danmarsden-AT-yahoo.co.uk> wrote:
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.
I think one difference here may be that Joel already knows he has interface-breaking changes planned (if that's not actually the case, I apologize). Several libraries have had interface-breaking changes after acceptance, but AFAIK these were not anticipated at the time of the review.
Yes, I do anticipate interface-breaking changes. The proto port (What we call V3) is special because it actually captures a lot of what I had in mind for the next revision. I also expect, as typical with a review, more changes that I haven't foreseen. The suggested "optional- laziness" and the new and improved switch_ syntax, are two such cases of high consideration. I thought it would make sense to addess all these in one step. Again, let me reiterate, that despite all these changes, the design and implementation or V2 is still sound, and IMO, pretty much up to standards with Boost quality. It is still the solid basis for V3 with up to 95% of the interface intact and essentially unchanged design and structure. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
on Sun Sep 28 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
I think one difference here may be that Joel already knows he has interface-breaking changes planned (if that's not actually the case, I apologize). Several libraries have had interface-breaking changes after acceptance, but AFAIK these were not anticipated at the time of the review.
Yes, I do anticipate interface-breaking changes. The proto port (What we call V3) is special because it actually captures a lot of what I had in mind for the next revision. I also expect, as typical with a review, more changes that I haven't foreseen. The suggested "optional- laziness" and the new and improved switch_ syntax, are two such cases of high consideration. I thought it would make sense to addess all these in one step.
Again, let me reiterate, that despite all these changes, the design and implementation or V2 is still sound, and IMO, pretty much up to standards with Boost quality. It is still the solid basis for V3 with up to 95% of the interface intact and essentially unchanged design and structure.
In case *I* wasn't sufficiently clear about it, let me try to be painfully explicit: we may want to discuss whether it's good for Boost or its users if we release a new top-level library and then break its interface in the next release, three months later. I'm all for accepting some version of Phoenix, but I want to make sure that users' needs for -- and the public perception of -- Boost's stability are accounted for. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
In case *I* wasn't sufficiently clear about it, let me try to be painfully explicit: we may want to discuss whether it's good for Boost or its users if we release a new top-level library and then break its interface in the next release, three months later. I'm all for accepting some version of Phoenix, but I want to make sure that users' needs for -- and the public perception of -- Boost's stability are accounted for.
Also please note that most major Linux distributions are still back at 1.33 or 1.34. Even if the next boost release would be only 3 months away, it may take a long while until the new release makes it into any major Linux distribution. It would be quite unfortunate if some distro happened to upgrade boost between the two Phoenix releases. There was an attempt to upgrade to 1.36 in the forthcoming Fedora 10, but API incompatibilities caused the idea to be dropped, the schedule was too tight for resolving all the problems. More details can be found for example here: http://www.linux-archive.org/fedora-development/141634-major-boost-breakage.... --> Mika Heiskanen / FMI
Mika Heiskanen wrote:
David Abrahams wrote:
In case *I* wasn't sufficiently clear about it, let me try to be painfully explicit: we may want to discuss whether it's good for Boost or its users if we release a new top-level library and then break its interface in the next release, three months later. I'm all for accepting some version of Phoenix, but I want to make sure that users' needs for -- and the public perception of -- Boost's stability are accounted for.
Also please note that most major Linux distributions are still back at 1.33 or 1.34. Even if the next boost release would be only 3 months away, it may take a long while until the new release makes it into any major Linux distribution. It would be quite unfortunate if some distro happened to upgrade boost between the two Phoenix releases.
Understood 100%. Such a thing will not happen. There will only be one release. That release will take into account all that's discussed in the review. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: 29 September 2008 12:59 To: boost@lists.boost.org Subject: Re: [boost] [Review] Phoenix review starts today, September 21st
Again, let me reiterate, that despite all these changes, the design and implementation or V2 is still sound, and IMO, pretty much up to standards with Boost quality. It is still the solid basis for V3 with up to 95% of the interface intact and essentially unchanged design and structure.
In case *I* wasn't sufficiently clear about it, let me try to be painfully explicit: we may want to discuss whether it's good for Boost or its users if we release a new top-level library and then break its interface in the next release, three months later. I'm all for accepting some version of Phoenix, but I want to make sure that users' needs for -- and the public perception of -- Boost's stability are accounted for.
I don't see that providing V3 *as well as V2* is breaking anything. Surely it is quite clear that V2 and V3 are different beasts, and if you want to jump from one to the other, you risk some trouble. This is price of improvement : I think Joel's proposed way of managing it is fine. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
On Mon, Sep 29, 2008 at 9:14 AM, Paul A Bristow <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: 29 September 2008 12:59 To: boost@lists.boost.org Subject: Re: [boost] [Review] Phoenix review starts today, September 21st
Again, let me reiterate, that despite all these changes, the design and implementation or V2 is still sound, and IMO, pretty much up to standards with Boost quality. It is still the solid basis for V3 with up to 95% of the interface intact and essentially unchanged design and structure.
In case *I* wasn't sufficiently clear about it, let me try to be painfully explicit: we may want to discuss whether it's good for Boost or its users if we release a new top-level library and then break its interface in the next release, three months later. I'm all for accepting some version of Phoenix, but I want to make sure that users' needs for -- and the public perception of -- Boost's stability are accounted for.
I don't see that providing V3 *as well as V2* is breaking anything.
Surely it is quite clear that V2 and V3 are different beasts, and if you want to jump from one to the other, you risk some trouble.
This is price of improvement : I think Joel's proposed way of managing it is fine.
As I understand Joel's proposal he intends to never release V2 as a top-level library but instead release V3 as an upgrade to Boost.Lambda. That's certainly a good way to go, and I support it. But if that's the case, let's review V3 when it's ready for review rather than giving our stamp of approval to V2. Again, there are several reasons V2 should remain in Boost.Spirit and not become a top-level library: yet another incompatible bind, yet more incompatible placeholders, etc. But there is every reason that V3 should eventually become the top-level replacement of Boost.Lambda: extendability via Proto, compatibility (at last) between lambda, bind, std::placeholders, etc. So though I vote no on accepting V2 as a top-level library, I support the plan and look forward to the actual final product. Daniel Walker
Daniel Walker wrote:
As I understand Joel's proposal he intends to never release V2 as a top-level library but instead release V3 as an upgrade to Boost.Lambda. That's certainly a good way to go, and I support it. But if that's the case, let's review V3 when it's ready for review rather than giving our stamp of approval to V2. Again, there are several reasons V2 should remain in Boost.Spirit and not become a top-level library: yet another incompatible bind, yet more incompatible placeholders, etc. But there is every reason that V3 should eventually become the top-level replacement of Boost.Lambda: extendability via Proto, compatibility (at last) between lambda, bind, std::placeholders, etc. So though I vote no on accepting V2 as a top-level library, I support the plan and look forward to the actual final product.
I think your points are valid. IMO, a full (re-)review of v3 would largely cover the same ground as the current v2 review. Perhaps as a compromise, we could wind up the v2 review with a basic yea or nea. If we agree we want phoenix, we can put phoenix v3 up for a mini-review before it is merged to trunk. The review would focus on: - Whether the feedback from the v2 review was accommodated - The new extensibility mechanism - The breaking interface changes from v2 - The migration path from lambda to phoenix - Interoperability with boost::bind and std::bind - Interoperability with other Proto-based DSELs - Compile times I see phoenix v3 as a hugely important step toward Boost's DSEL unification, so I'm generally in favor of getting more eyes on it before it's shipped. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Mon, Sep 29, 2008 at 12:06 PM, Eric Niebler <eric@boost-consulting.com> wrote:
Daniel Walker wrote:
As I understand Joel's proposal he intends to never release V2 as a top-level library but instead release V3 as an upgrade to Boost.Lambda. That's certainly a good way to go, and I support it. But if that's the case, let's review V3 when it's ready for review rather than giving our stamp of approval to V2. Again, there are several reasons V2 should remain in Boost.Spirit and not become a top-level library: yet another incompatible bind, yet more incompatible placeholders, etc. But there is every reason that V3 should eventually become the top-level replacement of Boost.Lambda: extendability via Proto, compatibility (at last) between lambda, bind, std::placeholders, etc. So though I vote no on accepting V2 as a top-level library, I support the plan and look forward to the actual final product.
I think your points are valid. IMO, a full (re-)review of v3 would largely cover the same ground as the current v2 review. Perhaps as a compromise, we could wind up the v2 review with a basic yea or nea. If we agree we want phoenix, we can put phoenix v3 up for a mini-review before it is merged to trunk. The review would focus on:
- Whether the feedback from the v2 review was accommodated - The new extensibility mechanism - The breaking interface changes from v2 - The migration path from lambda to phoenix - Interoperability with boost::bind and std::bind - Interoperability with other Proto-based DSELs - Compile times
I see phoenix v3 as a hugely important step toward Boost's DSEL unification, so I'm generally in favor of getting more eyes on it before it's shipped.
This sounds reasonable to me. Could I vote for acceptance on the condition of passage of a final code review prior to release? In other words, release of the final V3 would be subject to a formal review and a consensus vote that everything is good to go. Replacing Boost.Lambda is a big enough deal to merit two reviews, actually. Daniel Walker
Daniel Walker wrote:
On Mon, Sep 29, 2008 at 12:06 PM, Eric Niebler <eric@boost-consulting.com> wrote:
Daniel Walker wrote:
As I understand Joel's proposal he intends to never release V2 as a top-level library but instead release V3 as an upgrade to Boost.Lambda. That's certainly a good way to go, and I support it. But if that's the case, let's review V3 when it's ready for review rather than giving our stamp of approval to V2. Again, there are several reasons V2 should remain in Boost.Spirit and not become a top-level library: yet another incompatible bind, yet more incompatible placeholders, etc. But there is every reason that V3 should eventually become the top-level replacement of Boost.Lambda: extendability via Proto, compatibility (at last) between lambda, bind, std::placeholders, etc. So though I vote no on accepting V2 as a top-level library, I support the plan and look forward to the actual final product. I think your points are valid. IMO, a full (re-)review of v3 would largely cover the same ground as the current v2 review. Perhaps as a compromise, we could wind up the v2 review with a basic yea or nea. If we agree we want phoenix, we can put phoenix v3 up for a mini-review before it is merged to trunk. The review would focus on:
- Whether the feedback from the v2 review was accommodated - The new extensibility mechanism - The breaking interface changes from v2 - The migration path from lambda to phoenix - Interoperability with boost::bind and std::bind - Interoperability with other Proto-based DSELs - Compile times
I see phoenix v3 as a hugely important step toward Boost's DSEL unification, so I'm generally in favor of getting more eyes on it before it's shipped.
This sounds reasonable to me. Could I vote for acceptance on the condition of passage of a final code review prior to release? In other words, release of the final V3 would be subject to a formal review and a consensus vote that everything is good to go. Replacing Boost.Lambda is a big enough deal to merit two reviews, actually.
I'm in favor of a second review. I think that's a reasonable solution. I slept after reading Giovanni's post, which I though was the hardest to answer: Giovanni Piero Deretta wrote:
So, assuming that phoenix will be accepted, on what will be based as the first official phoenix release in boost? On the current implementation (with minor improvements like result_of compatiblity) or on a proto-based variant (like phoenix v3).
In the first case it means that when-if a proto based is available, it might break compatibility with any eventual user extensions.
In the second case it is a bit tricky for a reviewer point of view, because part of the library under review (notably the extension hooks) is not what will end up in boost.
Even if the second point were the adopted solution, I would still vote in favor of Phoenix because, seeing the precedents, I would trust Joel to come up with a good implementation, but I think it would be a bit against the spirit of a boost review.
Note that I think that the extension interface (and its documentation) is the most important part of Phoenix because, IMHO, it is where the "added value" with respect to boost.lambda lies.
The best solution would be that the implementation that goes into boost will be based on proto *and* will retain more or less the same extension interface.
I didn't have an answer and to be honest, he's right! I couldn't answer this one because I do not have a detailed road-map as to how the extension mechanism would be supported in the post V2 world: the proto rendition. While the interface remains mostly stable, the extension interface is the part that gets the biggest hit from the proto port. The current proto version of the extension is admitedly not good enough. And I do agree with Giovanni that it is, at least, one of the most important parts of Phoenix. Eric's proposal solves this dilemma. I'm all for a second review. The review has proven to be sooo productive. I'm very pleased with the amount of feedback that it has generated. I enjoy reading each post and comment from such highly intelligent people and I want to have more of it, just to make sure that we are on the right track. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On Mon, Sep 29, 2008 at 8:35 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
Eric's proposal solves this dilemma. I'm all for a second review. The review has proven to be sooo productive. I'm very pleased with the amount of feedback that it has generated. I enjoy reading each post and comment from such highly intelligent people and I want to have more of it, just to make sure that we are on the right track.
Excellent! So I think we may have some unanimity here, and I'm quite pleased to change my vote and join in. So... For the record, I hereby vote to Accept Phoenix on condition of a second review before the release. :-) Daniel Walker
Daniel Walker wrote:
On Mon, Sep 29, 2008 at 8:35 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
Eric's proposal solves this dilemma. I'm all for a second review. The review has proven to be sooo productive. I'm very pleased with the amount of feedback that it has generated. I enjoy reading each post and comment from such highly intelligent people and I want to have more of it, just to make sure that we are on the right track.
Excellent! So I think we may have some unanimity here, and I'm quite pleased to change my vote and join in. So...
For the record, I hereby vote to Accept Phoenix on condition of a second review before the release. :-)
Thank you! Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
I'm also in support of a second review for V3. Until the discussion sparked by Daniel I was not very clear on the motivation for the current review, but Eric's proposal sounds like a perfect way to move forward. I have not used Phoenix, or even Lambda, but I do have some experience working with Proto. If/when Phoenix V3 is under review, I'll be happy to dig into the implementation details and (time permitting) write a proper review. Cheers, Patrick On Mon, Sep 29, 2008 at 8:47 PM, Joel de Guzman <joel@boost-consulting.com>wrote:
Daniel Walker wrote:
On Mon, Sep 29, 2008 at 8:35 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
Eric's proposal solves this dilemma. I'm all for a second review. The review has proven to be sooo productive. I'm very pleased with the amount of feedback that it has generated. I enjoy reading each post and comment from such highly intelligent people and I want to have more of it, just to make sure that we are on the right track.
Excellent! So I think we may have some unanimity here, and I'm quite pleased to change my vote and join in. So...
For the record, I hereby vote to Accept Phoenix on condition of a second review before the release. :-)
Thank you!
Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Mon Sep 29 2008, Eric Niebler <eric-AT-boost-consulting.com> wrote:
IMO, a full (re-)review of v3 would largely cover the same ground as the current v2 review. Perhaps as a compromise, we could wind up the v2 review with a basic yea or nea. If we agree we want phoenix, we can put phoenix v3 up for a mini-review before it is merged to trunk. The review would focus on:
- Whether the feedback from the v2 review was accommodated - The new extensibility mechanism - The breaking interface changes from v2 - The migration path from lambda to phoenix - Interoperability with boost::bind and std::bind - Interoperability with other Proto-based DSELs - Compile times
I see phoenix v3 as a hugely important step toward Boost's DSEL unification, so I'm generally in favor of getting more eyes on it before it's shipped.
At first glance, not a bad compromise. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Sun Sep 28 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
I think one difference here may be that Joel already knows he has interface-breaking changes planned (if that's not actually the case, I apologize). Several libraries have had interface-breaking changes after acceptance, but AFAIK these were not anticipated at the time of the review. Yes, I do anticipate interface-breaking changes. The proto port (What we call V3) is special because it actually captures a lot of what I had in mind for the next revision. I also expect, as typical with a review, more changes that I haven't foreseen. The suggested "optional- laziness" and the new and improved switch_ syntax, are two such cases of high consideration. I thought it would make sense to addess all these in one step.
Again, let me reiterate, that despite all these changes, the design and implementation or V2 is still sound, and IMO, pretty much up to standards with Boost quality. It is still the solid basis for V3 with up to 95% of the interface intact and essentially unchanged design and structure.
In case *I* wasn't sufficiently clear about it, let me try to be painfully explicit: we may want to discuss whether it's good for Boost or its users if we release a new top-level library and then break its interface in the next release, three months later. I'm all for accepting some version of Phoenix, but I want to make sure that users' needs for -- and the public perception of -- Boost's stability are accounted for.
Agreed 100%. I wouldn't want to have a release that will be good for only a few months and break the interface in the next release. That's the last thing I would want to do. I value stability. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On Mon, Sep 29, 2008 at 3:19 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
David Abrahams wrote:
on Sun Sep 28 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
I think one difference here may be that Joel already knows he has interface-breaking changes planned (if that's not actually the case, I apologize). Several libraries have had interface-breaking changes after acceptance, but AFAIK these were not anticipated at the time of the review.
Yes, I do anticipate interface-breaking changes. The proto port (What we call V3) is special because it actually captures a lot of what I had in mind for the next revision. I also expect, as typical with a review, more changes that I haven't foreseen. The suggested "optional- laziness" and the new and improved switch_ syntax, are two such cases of high consideration. I thought it would make sense to addess all these in one step.
Again, let me reiterate, that despite all these changes, the design and implementation or V2 is still sound, and IMO, pretty much up to standards with Boost quality. It is still the solid basis for V3 with up to 95% of the interface intact and essentially unchanged design and structure.
In case *I* wasn't sufficiently clear about it, let me try to be painfully explicit: we may want to discuss whether it's good for Boost or its users if we release a new top-level library and then break its interface in the next release, three months later. I'm all for accepting some version of Phoenix, but I want to make sure that users' needs for -- and the public perception of -- Boost's stability are accounted for.
Agreed 100%. I wouldn't want to have a release that will be good for only a few months and break the interface in the next release. That's the last thing I would want to do. I value stability.
So, assuming that phoenix will be accepted, on what will be based as the first official phoenix release in boost? On the current implementation (with minor improvements like result_of compatiblity) or on a proto-based variant (like phoenix v3). In the first case it means that when-if a proto based is available, it might break compatibility with any eventual user extensions. In the second case it is a bit tricky for a reviewer point of view, because part of the library under review (notably the extension hooks) is not what will end up in boost. Even if the second point were the adopted solution, I would still vote in favor of Phoenix because, seeing the precedents, I would trust Joel to come up with a good implementation, but I think it would be a bit against the spirit of a boost review. Note that I think that the extension interface (and its documentation) is the most important part of Phoenix because, IMHO, it is where the "added value" with respect to boost.lambda lies. The best solution would be that the implementation that goes into boost will be based on proto *and* will retain more or less the same extension interface. -- gpd
On Mon, Sep 29, 2008 at 9:33 AM, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
Note that I think that the extension interface (and its documentation) is the most important part of Phoenix because, IMHO, it is where the "added value" with respect to boost.lambda lies.
The best solution would be that the implementation that goes into boost will be based on proto *and* will retain more or less the same extension interface.
I agree that extensibility via Proto is an important innovation, and as Phoenix V3 moves out of the alpha stage, this could be mind-blowing in the Boost.Lambda world! Daniel
Daniel Walker wrote:
On Mon, Sep 29, 2008 at 9:33 AM, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
Note that I think that the extension interface (and its documentation) is the most important part of Phoenix because, IMHO, it is where the "added value" with respect to boost.lambda lies.
The best solution would be that the implementation that goes into boost will be based on proto *and* will retain more or less the same extension interface.
I agree that extensibility via Proto is an important innovation, and
Just to be clear: the phoenix extension mechanism has been in place from day one (since phoenix1). It is a hallmark of the design that has proven to be very powerful. It allowed us to extend the library in a modular manner non-intrusively. All libraries I have written since then has incorporated some form of extension mechanism. The API basically has two parts, one is the general user API, one is the extension API. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
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
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
David Abrahams: ...
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.
I think I disagree, for entirely practical reasons. First, I very much suspect that the relative lack of exposure to the wider Boost community has held Phoenix back. It would have been a better library now had it been at top level. More so, had it been labeled as the way forward for Lambda users. For me, this formal review, formal in the formality sense, has already been delayed far too much. Second, things always take longer than planned. Waiting for Phoenix V3 may turn out to not be a particularly good idea, in hindsight. PS: lambda()[ ... ] should work and be an alias for lambda[ ... ]. :-)
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 30 September 2008 14:29 To: boost@lists.boost.org Subject: Re: [boost] [Review] Phoenix review starts today, September 21st
David Abrahams: ...
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.
I think I disagree, for entirely practical reasons. First, I very much suspect that the relative lack of exposure to the wider Boost community has held Phoenix back. It would have been a better library now had it been at top level. More so, had it been labeled as the way forward for Lambda users. For me, this formal review, formal in the formality sense, has already been delayed far too much.
Second, things always take longer than planned. Waiting for Phoenix V3 may turn out to not be a particularly good idea, in hindsight.
I too am concerned that failure to accept V2 into Boost now will mean that far fewer people try to use Phoenix and thus the number of people able to contribute to a V3 review will be far less. As many have observed, people are reluctant to use libraries unless they are in the regular release. (I know Phoenix V2 is available in Spirit, but I'm not sure people will find it, or see why they should use it. Joel's documentation to V2 makes it clear what it all about and when to use it.) As long as we are totally upfront about V2 being a stepping stone to V3, I doubt if the supposed gain in stability is really worth it. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
on Tue Sep 30 2008, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
David Abrahams: ...
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.
I think I disagree, for entirely practical reasons. First, I very much suspect that the relative lack of exposure to the wider Boost community has held Phoenix back. It would have been a better library now had it been at top level.
Agreed 100%. I wish it were at the top level long ago... before the proto rewrite was even initiated.
More so, had it been labeled as the way forward for Lambda users.
It has been so labelled, but only unofficially. I for one have been itching to jump.
For me, this formal review, formal in the formality sense, has already been delayed far too much.
Also agreed 100%.
Second, things always take longer than planned. Waiting for Phoenix V3 may turn out to not be a particularly good idea, in hindsight.
Again, agreed.
PS: lambda()[ ... ] should work and be an alias for lambda[ ... ]. :-)
Would be nice. So, we agree. On what point were you disagreeing with me? :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, Sep 30, 2008 at 8:42 AM, David Abrahams <dave@boostpro.com> wrote:
Once again, said better than I ever could.
Thanks! But I'm just restating things I learn from this list... and from a few colleagues... and a few teachers along the way. ;-)
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.
I feel comfortable with Eric's compromise. And even if it's premature, some good things have come out of this current review... which is to say that it can be good to have multiple reviews. I for one would be even more confident in a library that had been hammered out through multiple review/rejection cycles before finally being accepted. So, it wouldn't be bad if Boost accepted fewer libraries after the first review, when multiple reviews are merited, of course. As for Phoenix, whether the second review comes as a result of rejection in the first or as a condition of acceptance in the first, either way, it will have the benefit of a final review before it's released, which is the important thing. Daniel Walker
participants (10)
-
dan marsden -
Daniel Walker -
David Abrahams -
Eric Niebler -
Giovanni Piero Deretta -
Joel de Guzman -
Mika Heiskanen -
Patrick Mihelich -
Paul A Bristow -
Peter Dimov