Am 23. August 2015 18:13:52 MESZ, schrieb "Vicente J. Botet Escriba" :

Niall, Ahmed, it will be very difficult to review this library as it has dependencies on libraries that are not adopted by Boost. The documentation is full of references to both libraries APBind and Monad.

If they are internals, no mention should be done on the documentation.

AFAIK Monad is visible to the user as AFIO functions return them. Cheers -Andreas -- Sent from my mobile. No type gold.

On 8/25/15 4:37 AM, Paul A. Bristow wrote:

Please answer the following questions:

1. Should Boost.AFIO be accepted into Boost? Please state all conditions for acceptance explicity.

Provisionally, yes.

Requirements: <snip>

This list of requirements constitutes much more than a "a few changes". It's impossible to know what what the library would like like after all these changes and and their repercussions were addressed. I don't think we can realistically expect the review manager to verify that and library with all these changes is sufficiently close the current one to take responsibility for signing off on the final version. To my mind, this would require a new review once all the changes are made. So the appropriate recommendation in this case would be to reject the library and encourage the author to consider all the feedback from the review and re-submit. Robert Ramey

On 8/25/15 10:28 AM, Niall Douglas wrote:

There is precedent for this: Boost.Fiber was provisionally approved here as a C++ 98 library with condition of a mini-review before entry. Boost.Fiber is now a C++ 14 library and sufficiently different from the library originally reviewed it may require a second mini-review if during its first mini-review it is felt still lacking.

This is a precedent - a bad one which I hope to avoid a repetition of in the future. A library which is accepted should be close enough to it's final state so that it can be finished up on the order of a couple of months and will result in a final version which is close to what reviewers actually reviewed. We can't have a library pass a review, then have the package morph into something significantly different then have it accepted. This make the original review a farce.

I think this pattern of repeated mini-reviews caused by changes to the common implementations of the C++ standard rather than the libraries themselves is going to be very common next few years.

LOL - maybe, but only if we let it. All

these changes to AFIO are almost entirely driven by changes since 2012 to the various WG21 technical standards. If they hadn't changed and C++ compilers (specifically MSVC) hadn't changed, AFIO wouldn't have changed.

It's very similar for Fiber, which had to be refactored in the face of substantial changes in C++ 14.

I seriously doubt that a package which compiles and passes tests and reviews with C++03 cannot do these things when C++11 comes out. What really happens is that the author sees opportunities with C++11 that he didn't have before then starts incorporating them after the original review. I guess this would be called feature creep or implementation creep. In any case, it indicates that the original acceptance was premature. Ultimately it hinges on what "acceptance into Boost" means. To me it's a library ready - with a few straight forward / uncontroversial changes which is ready to be incorporated into the boost distribution. It's not acceptance of an idea for a library, a prototype for a library, or that a developer is certified to add a library in the future. Robert Ramey

On 8/25/15 4:37 AM, Paul A. Bristow wrote:

IMO what we are deciding is if we want this software to be developed and maintained, not, as some mistakenly imagine, if it is finished > and complete ready to go into the 1.60 release. It isn’t and won’t be until 1.61 at the very earliest, and will still be modified after > > release because

It is using cutting edge tools.

It is breaking new ground and will be changes by C++ Standard, Library and compiler changes.

Personally, I don’t believe that Incubator is the right way to speed development of this software.

Hmmm - why not?

I think we need to alter the Boost review and acceptance process.

In what way?

I favour accepting this quite mature software and being prepared for it to change as a result of user experience. It won’t get users until it is part of a release, as we are running things at present.

What is to be gained by this? Given the scope of the changes you've cited, it would have to be re-reviewed anyway. And aamini-review or re-review by the release manager would not be sufficiently exhaustive and would not draw enough people to repeat the process. Likely it would result in acceptence a library which hasn't really been scrutinized - which the outcome which I aspire to prevent. What does "accept" mean here. That we think it has promise but needs work? To me it means that this library is basically correct and with some straightforward changes will meet the boost user's expectations. There is no reason that a library which is not accepted cannot be developed further in order to meet Boost's requirements and be re-submitted. I know for a fact that this is true because that's what I did. Robert Ramey

Paul wrote:

I think it will never take off until 'official'. That is most unreasonable, but a fact of life.

I was under the impression that the Incubator was official (or at least officially endorsed, just not mandated as part of the review process). Glen -- View this message in context: http://boost.2283326.n4.nabble.com/boost-afio-Formal-review-of-Boost-AFIO-tp... Sent from the Boost - Users mailing list archive at Nabble.com.

Paul wrote:

...

I think it will never take off until 'official'. That is most unreasonable, but a fact of life.

I was under the impression that the Incubator was official (or at least officially endorsed, just not mandated as part of the review process).

If its officially endorsed, then there should be a link to it on boost.org. There is still a link to the no longer used sandbox. The sandbox should ultimately be replaced by the incubator. Paul -- View this message in context: http://boost.2283326.n4.nabble.com/boost-afio-Formal-review-of-Boost-AFIO-tp... Sent from the Boost - Users mailing list archive at Nabble.com.

On 8/26/15 4:11 AM, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 25 August 2015 20:20 To: boost-users@lists.boost.org Subject: Re: [Boost-users] [boost] [afio] Formal review of Boost.AFIO

On 8/25/15 4:37 AM, Paul A. Bristow wrote:

...

Personally, I don't believe that Incubator is the right way to speed > development of this software.

Hmmm - why not?

I think it will never take off until 'official'. That is most unreasonable, but a fact of life.

I'm not convinced of this. I think that if something works well and serves a real need, people will use it and it will eventually be "co-opted" by "official" institutions. If this isn't happening with the incubator - it's because it isn't deemed useful enough - at least for it's original intended purpose. The only real purpose of the "official" institutions is to give the impression that the process is more orderly than it actually is. The incubator get's around 1000 vists / month. It's also surprisingly easy to maintain - requires hardly any time to keep it running. So I'm dis-inclined to write it off entirely. Making improvements does consume a lot of time unfortunately. So my point of view would be that the incubator needs to evolve or perhaps change it's stated goal. At that time it was conceived, a huge concern was the lack of persons willing to be review managers. Lately this concern has been less in the news. I'm not sure why that is, maybe it's a coincidence or maybe it has worked in some way that I don't understand. My original vision was that it would avoid the situation where a library author thinks he's done and submits a library and it's really not. So that a huge amount of effort is wasted by library author and reviewers. Lately it seems we have more reviewers also so this situation seem quite so urgent. Another thing I was that I wanted to preserve the history and commentary on libraries in a convenient way. To me, a boost library is much more than a bunch of C++ code. The documentation, discussion, etc. is an essential part of the package. I feel that much valuable information on libraries such as rationale for design decisions, reasons for rejection, etc. .. is "lost". Technically it might not be lost - but it's hard to dig up on a convenient manner. So I invested effort in a system for comments/reviews with comments etc modeled on the developer's list. I've been disappointed that this hasn't taken hold. This aspect needs some new ideas which haven't occurred to me yet.

...

...

I think we need to alter the Boost review and acceptance process.

...

In what way?

Having two 'status' flags:

* mature and 'standard' - stable and bug-free (we hope). * 'experimental' - usable but still be being improved.

The C++ Standards people have started to accept the need for 'experimental' status.

(Of course, the 'status' is really a continuum, not a bool).

Bottom line, I think Boost works because it limits it scope to some relatively simple rules and passes judgement whether or not various initiatives meet those rules. It doesn't really DO anything other than that. In line with this - I think the review process should continue to confine itself mostly passing judgement on submissions and limit it's active design/intervention/management/promotion of the library development itself.

My main reason is that I believe that people won't use libraries until they are in the release.

That's because people have come to depend on the boost "brand" as sign of quality. Diluting this brand by "accepting conditionally" or otherwise promoting libraries which don't meet our standards for quality and completeness will be counter productiive.

And without lots of users ("first encounter with the enemy") , you don't find if things are really useful or not.

IMO, too many Boost reviews are by far too few people and with too little real-life use.

Ahhh - on this we agree. I would hope that we could more people to use libraries which have been submitted before they are actually reviewed and that these people could be encouraged to make reviews. I think that the major obstacle is that most libraries that the authors think are good are just not good enough. Most authors underestimate the requirements of the "customers" and think that "good code" is enough. (Besides over-estimating the quality of their code). I did make a presentation on this subject at Boost Con 2014. https://www.youtube.com/watch?v=ACeNgqBKL7E Attendance was an underwhelming 14 attendees. LOL - my life is filled with disappointments. Robert Ramey

Ahmed wrote:

I have reviews from the following people: - Roland Bock - Paul A. Bristow - Thomas Heller - Hartmut Kaiser - Jeremy Maitin-Shepard

There is also a review from: - Andreas Schäfer Glen -- View this message in context: http://boost.2283326.n4.nabble.com/boost-afio-Formal-review-of-Boost-AFIO-tp... Sent from the Boost - Users mailing list archive at Nabble.com.