Hi, I will be out for two weeks and I wanted to at least give the result of the Boost.Fit library review even if I would need more time to have a complete report. Summary ======= The review of the proposed Boost.Fit library ended on Mars 20, 2016. The verdict is: Conditional acceptance (a new review is needed) There were too much concerns about the documentation and what exactly this library is proposing and not enough reviews commenting the design, code and test for each one of the proposed functions. From the review discussion I deduce that there is some interest in the library, and that some people don't understand yet what the library is proposing. Paul has started already to take in account some if the issues raised during the review and a lot of them must be resolved before we re-try a new review. There were some discussion about the name of the library, but there were no consensus. Paul is free to change the name of his library and see how people react. On behalf of the Boost community, I would like to thank Paul Fultz for the work he has put into the Fit library so far. I encourage him to continue to evolve this library and to bring it back for a new review. We had seven 6 formal votes, and 2 more votes without a complete review abbreviated here: Steaven Watanabe: No in his current state Zach Laine : Conditinal acceptance Krzysztof Jusiak: Accepted Artyom Beilis : Rejected Peter Dimov : Accepted (no review) Manuel Sancher : Accepted (no review) Rob Stewart : Conditinal acceptance ??? Louis Dionne : Conditinal acceptance There were other people that participated on the review giving their advice respect to a specific issue. I thank each of these reviewers, and indeed everyone who invested some time participating in the discussions. If you feel that I have misrepresented your position, or have omitted or garbled an important point, please respond: the archived mail thread should accurately reflect the will of the community, even if this message does not. Detailed Report =============== You will need to wait yet for a month before I will be able to do it. On the mean time there are a lot of issues that must be addressed and that are part of the github issues. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Issues:https://github.com/pfultz2/Fit/issues Documentation:http://pfultz2.github.io/Fit/doc/html/ Hopping this helps, Vicente Botet Escriba
On 4/3/16 7:36 AM, Vicente J. Botet Escriba wrote:
The review of the proposed Boost.Fit library ended on Mars 20, 2016. The verdict is:
Conditional acceptance (a new review is needed)
snip ... The about could be more accurately and succinctly stated: That is the library is rejected. The effort is not without merit and the author is encouraged to address the concerns raised by the reviewers and re submit the library. I followed comments on the review fairly closely. I think that submitters could improve their chances of success by doing somethings differently. I've always been forth coming on giving advice to these authors. Of course, unsolicited advice isn't generally effective, but its good therapy for those that offer it. In that vain I offer the youtube video of my presentation at CppCon 2014 "How you can make a Boost C++ Library". I was sort of stunned by the lack of interest - only 14 attendees and pretty disappointed by the reception - about average according to statistics. Oh well, one keeps trying. Robert Ramey
On Apr 3, 2016, at 11:19 AM, Robert Ramey <ramey@rrsd.com> wrote:
On 4/3/16 7:36 AM, Vicente J. Botet Escriba wrote:
The review of the proposed Boost.Fit library ended on Mars 20, 2016. The verdict is:
Conditional acceptance (a new review is needed)
snip ...
The about could be more accurately and succinctly stated:
That is the library is rejected.
The effort is not without merit and the author is encouraged to address the concerns raised by the reviewers and re submit the library.
I followed comments on the review fairly closely. I think that submitters could improve their chances of success by doing somethings differently. I've always been forth coming on giving advice to these authors. Of course, unsolicited advice isn't generally effective, but its good therapy for those that offer it. In that vain I offer the youtube video of my presentation at CppCon 2014 "How you can make a Boost C++ Library". I was sort of stunned by the lack of interest - only 14 attendees and pretty disappointed by the reception - about average according to statistics. Oh well, one keeps trying.
What are you suggesting I should’ve done differently?
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 4/3/16 9:56 AM, P F wrote:
On Apr 3, 2016, at 11:19 AM, Robert Ramey <ramey@rrsd.com> wrote:
On 4/3/16 7:36 AM, Vicente J. Botet Escriba wrote:
The review of the proposed Boost.Fit library ended on Mars 20, 2016. The verdict is:
Conditional acceptance (a new review is needed)
snip ...
The about could be more accurately and succinctly stated:
That is the library is rejected.
The effort is not without merit and the author is encouraged to address the concerns raised by the reviewers and re submit the library.
I followed comments on the review fairly closely. I think that submitters could improve their chances of success by doing somethings differently. I've always been forth coming on giving advice to these authors. Of course, unsolicited advice isn't generally effective, but its good therapy for those that offer it. In that vain I offer the youtube video of my presentation at CppCon 2014 "How you can make a Boost C++ Library". I was sort of stunned by the lack of interest - only 14 attendees and pretty disappointed by the reception - about average according to statistics. Oh well, one keeps trying.
What are you suggesting I should’ve done differently?
My views on the subject can be found on the boost library incubator. These are in large part reflected in the youtube video cited. The suggestions are pretty mundane but I think they add up to alot. You can find them there. But off the top of my head I can cite a few of them. Observations and assumptions: a) most C++ library documentation is much worse than it should be. This makes the library harder to use than it should be. b) Unhelpful documentation is often a reflection that the library itself lacks clear focus on its goals and purpose. The description of its implementation and usage ends up confusing and irregular. c) The usual sequence of events is to write all the code and maybe the tests and then write the documentation as afterwards. But in writing the documentation often reveals problems in the library itself - often times in a fundamental way. Now the author faces a dilemma: Does he move forward - take the library as a given and somehow patch together the documentation? or does he go back and adjust the library to make it simpler or more regular. If he does the latter, there is a huge danger that it's like pulling a thread from a sweater and everything ends up changing - then the documentation has to be done almost from scratch - again! Since he already spent 10 times the time orginally anticipated he just wraps it up. In the references cite above I have few concrete suggestions. a) Follow the original SGI documentation as a model for reference documentation. This is the first and best examples of how Type Requirements (aka concepts) drive the design of the library b) At some point near the beginning write the introduction to the documentation. This will require one to make a concise statement as to what problem the library is meant to solve and how it goes about doing it. This is generally only a paragraph or two so it should be easy. c) when you make a piece of code, make an example which demonstrates how to use it. When you think the example illustrates how the library is to be used and what problem it solves, then create a narrative page to explain this. d) make the reference part of the documentation for a type/class soon after you make the code and test. This will include the type requirements as well as reference on particular classes which model the type requirements. e) When you make a critical design trade-off, add a paragraph to the "rationale" section so you don't forget. f) Display and check the documentation as you go so you can verify that it reflects the reality of the code. g) by the time you think your code is "done" you should now have most of the documentation done. It's not a tedious chore that you had to do, it's part of the library development process. And you've made the process of development easier because there is less going back and redoing previous work. Of course there is still some of that, but it's less than it is if you wait until the end. It's less work and the work is less tedious. h) Now you think your "done" but before getting a formal review, try to rope someone into trying the library out from the documentation. Every time your "guinea pig" has to ask you a question, it's an opportunity to update your documentation so that that question never will be asked again. Or if it does you can just respond with "look at page 999 of the documentation" I realize that that getting such a "guinea pig" is not easy. It's one of the things I've tried to facilitate via the boost library incubator - with very little success. Actually, every time from now into the future, every time someone asks a question with a trac item or posting to the list should result in small enhancement to the documentation so that that question doesn't come up again. In this way you're constantly moving forward. So those are my concrete suggestions. I realize that C++ programmer thinks that this is a trivial task and the he knows how to do it. I also that I'm asking C++ programmers to respect my authority in this subject and this is a very large and bitter pill to swallow for those of use with large egos (which is basically all of us). All can say is: a) as the author of a very large and very complex library, the above has worked for me. b) just be willing to give it a try. It won't be any more unpleasant than what you're doing now and it just might work. Robert Ramey
On 4/3/16 7:36 AM, Vicente J. Botet Escriba wrote:
Hi,
I will be out for two weeks and I wanted to at least give the result of the Boost.Fit library review even if I would need more time to have a complete report.
Summary =======
The review of the proposed Boost.Fit library ended on Mars 20, 2016. The verdict is:
Conditional acceptance (a new review is needed)
There were too much concerns about the documentation and what exactly this library is proposing and not enough reviews commenting the design, code and test for each one of the proposed functions.
<snip> Given the text I snipped, I don't see how one could characterize the review result as "Conditionally Accepted" What is this suppossed to mean exactly. That it should be integrated into boost as soon as it meets some list of conditions? What are these? Who determines when they are met. I'd feel much more comfortable with something like The library is rejected. Many reviewers felt that the library had a lot of promise but needs significant alterations and/or enhancements before it can accepted into boost. The author is encouraged to address the issues raised in the review and resubmit it. Wouldn't the be a more accurate and fair assessment and better proposal for future action? Robert Ramey
On May 17, 2016, at 11:29 PM, Robert Ramey <ramey@rrsd.com> wrote:
On 4/3/16 7:36 AM, Vicente J. Botet Escriba wrote:
Hi,
I will be out for two weeks and I wanted to at least give the result of the Boost.Fit library review even if I would need more time to have a complete report.
Summary =======
The review of the proposed Boost.Fit library ended on Mars 20, 2016. The verdict is:
Conditional acceptance (a new review is needed)
There were too much concerns about the documentation and what exactly this library is proposing and not enough reviews commenting the design, code and test for each one of the proposed functions.
<snip>
Given the text I snipped, I don't see how one could characterize the review result as "Conditionally Accepted"
What is this suppossed to mean exactly. That it should be integrated into boost as soon as it meets some list of conditions? What are these? Who determines when they are met. I'd feel much more comfortable with something like
The library is rejected.
You did not take part of the review of the library and are not the review manager for it.
Many reviewers felt that the library had a lot of promise but needs significant alterations and/or enhancements before it can accepted into boost. The author is encouraged to address the issues raised in the review and resubmit it.
There were 6 votes for the library and 2 votes to reject. There were only two votes for conditional acceptance from Zach Laine and Louis Dionne. Talking to them personally, they did not intend for the library to be resubmitted(they listed there conditions for acceptance in the review).
On May 18, 2016 12:52:06 AM EDT, Paul Fultz II <pfultz2@yahoo.com> wrote:
On May 17, 2016, at 11:29 PM, Robert Ramey <ramey@rrsd.com> wrote:
On 4/3/16 7:36 AM, Vicente J. Botet Escriba wrote:
The review of the proposed Boost.Fit library ended on Mars 20, 2016. The verdict is:
Conditional acceptance (a new review is needed)
There were too much concerns about the documentation and what
exactly
this library is proposing and not enough reviews commenting the design, code and test for each one of the proposed functions.
<snip>
Given the text I snipped, I don't see how one could characterize the review result as "Conditionally Accepted"
What is this suppossed to mean exactly. That it should be integrated into boost as soon as it meets some list of conditions? What are these? Who determines when they are met. I'd feel much more comfortable with something like
The library is rejected.
You did not take part of the review of the library and are not the review manager for it.
Those points don't mean he can't question the meaning of Vicente's phrasing.
There were 6 votes for the library and 2 votes to reject. There were only two votes for conditional acceptance from Zach Laine and Louis Dionne. Talking to them personally, they did not intend for the library to be resubmitted(they listed there conditions for acceptance in the review).
Vicente will clarify his intent, but his post was somewhat ambiguous. Despite the intent of the reviewers, he could, as the Review Manager, reject the library and call for a new review after changes. He could, instead, list conditions you must meet to satisfy a conditional acceptance, but that's not certain at this point. ___ Rob (Sent from my portable computation engine)
Le 18/05/2016 à 10:29, Rob Stewart a écrit :
On May 18, 2016 12:52:06 AM EDT, Paul Fultz II <pfultz2@yahoo.com> wrote:
On May 17, 2016, at 11:29 PM, Robert Ramey <ramey@rrsd.com> wrote:
On 4/3/16 7:36 AM, Vicente J. Botet Escriba wrote:
The review of the proposed Boost.Fit library ended on Mars 20, 2016. The verdict is:
Conditional acceptance (a new review is needed)
There were too much concerns about the documentation and what exactly this library is proposing and not enough reviews commenting the design, code and test for each one of the proposed functions. <snip>
Given the text I snipped, I don't see how one could characterize the review result as "Conditionally Accepted" What is this suppossed to mean exactly. That it should be integrated into boost as soon as it meets some list of conditions? What are these? Who determines when they are met. I'd feel much more comfortable with something like The library is rejected. You did not take part of the review of the library and are not the review manager for it. Those points don't mean he can't question the meaning of Vicente's phrasing.
There were 6 votes for the library and 2 votes to reject. There were only two votes for conditional acceptance from Zach Laine and Louis Dionne. Talking to them personally, they did not intend for the library to be resubmitted(they listed there conditions for acceptance in the review). Vicente will clarify his intent, but his post was somewhat ambiguous. Despite the intent of the reviewers, he could, as the Review Manager, reject the library and call for a new review after changes. He could, instead, list conditions you must meet to satisfy a conditional acceptance, but that's not certain at this point.
Hi all, and sorry for not have my home work done yet. Robert, Rob, you are right that I could have rejected the library but I've preferred to accept it subject to a new review. The main reason is that I believe that this library would be useful for the C++ Boost community. It's not ready yet, but the features the library proposes are useful. Rob, the conditions will not be for conditional acceptance, but for having a new review. Sorry if this was not clear. with my sentence
Conditional acceptance (a new review is needed)
Unfortunately I've no time to do the report of the modifications that will be needed before the new review. The deadline for Oulu C++ standard committee is end of this month and I have some papers to finish. Please, be patient, Vicente
Robert, Rob, you are right that I could have rejected the library but I've preferred to accept it subject to a new review. The main reason is that I believe that this library would be useful for the C++ Boost community. It's not ready yet, but the features the library proposes are useful.
That's the way I read it.
Rob, the conditions will not be for conditional acceptance, but for having a new review. Sorry if this was not clear. with my sentence
Conditional acceptance (a new review is needed)
OK - I think that was widely misunderstood.
Unfortunately I've no time to do the report of the modifications that will be needed before the new review. The deadline for Oulu C++ standard committee is end of this month and I have some papers to finish.
Please, be patient,
No problem - I understand that it takes time to good job reviewing all the reviews. This is especially true when you don't really want to dismiss the submission outright but hope to see it transformed in some way. May main concern was it seemed accepted into boost subject to some conditions which were expected to be met - if not proforma. It seems that I got this wrong. I've objected in the past to the characterization of "conditionally accepted" in this context. Though I'm sympathetic to the idea that submission to boost should not be a gratuitously unpleasant process, I think attempting to "soften the blow" can lead to more frustration than less. I would also like to see us encourage pre-reviews on the incubator. I know this idea has not been successful, but I still think it's a good idea. I think it can be hugely helpful and motivating to library developers, improve quality of submissions and raise acceptance rate for library submissions. It can also wake up a library author to the fact that he's not really ready to submit - at much smaller cost in emotional frustration. For an example of how this can work, see the review in the safe numerics library. This one review made me re-think fundamental aspects of the submission in a way that otherwise wouldn't have happened. As I responded to the review and subsequent comments, I did a couple of things: a) I made the library simpler. It move toward a clearer and more unified concept as opposed to a disjoint bag of tricks. b) I had to make a better case about why I thought such a library was needed and worthwhile. The resulted in creating a bunch of tutorial examples illustrating the case where I thought such a library was necessary. Of course more examples made me think about the focus and feature set that was actually required. After this exchange - I worked another year on the library. If this library were to come up for review, one review is already done, in the queue and available for reference by other reviewers and/or review manager. I believe that the effort invested in this pre-review process will more than recovered in saving time in any final review and avoiding the dreaded "conditionally accepted" which is like your future ex-girlfriend telling you "I like you as friend". Also note that reviews posted in the incubator would be available to future users of the library and would be easily available to explain the rationale for all the decisions made - and all the features left out and all the arguments about this. It serves as an expanded FAQ. Robert Ramey
On May 18, 2016 2:18:16 PM EDT, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote:
On May 18, 2016 12:52:06 AM EDT, Paul Fultz II <pfultz2@yahoo.com> wrote:
On May 17, 2016, at 11:29 PM, Robert Ramey <ramey@rrsd.com> wrote: On 4/3/16 7:36 AM, Vicente J. Botet Escriba wrote:
The review of the proposed Boost.Fit library ended on Mars 20,
The verdict is:
Conditional acceptance (a new review is needed)
Given the text I snipped, I don't see how one could characterize
Le 18/05/2016 à 10:29, Rob Stewart a écrit : 2016. the
review result as "Conditionally Accepted" Vicente will clarify his intent, but his post was somewhat ambiguous.
Robert, Rob, you are right that I could have rejected the library but I've preferred to accept it subject to a new review.
That still seems confusing. If it needs a new, full review, in what way was it accepted? I presume you mean to suggest that you think it's close to acceptable, and you want to encourage Paul to finish the effort, but can't you couch a rejection in those terms? IOW, I understand you to be saying, "While the library will be a powerful and useful tool, it is not yet ready for Boost to accept. I very much want Paul to make the changes that have been suggested, and which he had accepted, and to resubmit his library in the near future. Nevertheless, I must reject the library in its present form." Does that not convey your intent well, including encouraging Paul to finish the task, without being contradictory like your formulation? ___ Rob (Sent from my portable computation engine)
On 19 May 2016 2:04 a.m., "Rob Stewart" <rstewart@ptd.net> wrote:
On May 18, 2016 2:18:16 PM EDT, "Vicente J. Botet Escriba" <
vicente.botet@wanadoo.fr> wrote:
On May 18, 2016 12:52:06 AM EDT, Paul Fultz II <pfultz2@yahoo.com> wrote:
On May 17, 2016, at 11:29 PM, Robert Ramey <ramey@rrsd.com> wrote: On 4/3/16 7:36 AM, Vicente J. Botet Escriba wrote:
The review of the proposed Boost.Fit library ended on Mars 20,
The verdict is:
Conditional acceptance (a new review is needed)
Given the text I snipped, I don't see how one could characterize
Le 18/05/2016 à 10:29, Rob Stewart a écrit : 2016. the
review result as "Conditionally Accepted" Vicente will clarify his intent, but his post was somewhat ambiguous.
Robert, Rob, you are right that I could have rejected the library but I've preferred to accept it subject to a new review.
That still seems confusing. If it needs a new, full review, in what way was it accepted? I presume you mean to suggest that you think it's close to acceptable, and you want to encourage Paul to finish the effort, but can't you couch a rejection in those terms?
There is an encouragement factor in a conditional acceptance, but the expectation is that the mini review would only need to touch the issues that the review manager feels need to be addressed instead of reevaluating the whole library. As a minimum, the question of whether the library is useful at all has already been positively answered. Finally the review manager really has lot of power and while they should guide their decision based on the review themselves, they only respond to the review wizards (I.e. there is no vote counting). -- gpd
Le 19/05/2016 à 03:04, Rob Stewart a écrit :
On May 18, 2016 2:18:16 PM EDT, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote:
On May 18, 2016 12:52:06 AM EDT, Paul Fultz II <pfultz2@yahoo.com> wrote:
On May 17, 2016, at 11:29 PM, Robert Ramey <ramey@rrsd.com> wrote: On 4/3/16 7:36 AM, Vicente J. Botet Escriba wrote:
The review of the proposed Boost.Fit library ended on Mars 20,
The verdict is:
Conditional acceptance (a new review is needed) Given the text I snipped, I don't see how one could characterize
Le 18/05/2016 à 10:29, Rob Stewart a écrit : 2016. the
review result as "Conditionally Accepted" Vicente will clarify his intent, but his post was somewhat ambiguous. Robert, Rob, you are right that I could have rejected the library but I've preferred to accept it subject to a new review. That still seems confusing. If it needs a new, full review, in what way was it accepted? I presume you mean to suggest that you think it's close to acceptable, and you want to encourage Paul to finish the effort, but can't you couch a rejection in those terms?
IOW, I understand you to be saying, "While the library will be a powerful and useful tool, it is not yet ready for Boost to accept. I very much want Paul to make the changes that have been suggested, and which he had accepted, and to resubmit his library in the near future. Nevertheless, I must reject the library in its present form."
Does that not convey your intent well, including encouraging Paul to finish the task, without being contradictory like your formulation?
Not exactly. As Giovanni has explained, a conditional acceptance means something different than rejecting the library. We have identified during the review a lot of points Paul is already taking care of. Most of them concerns the documentation, some the design, and not too much the implementation. The issues that must be fixed are most of them already reported in github. I have not identified any issue that couldn't be managed. What is missing is a report to the fixes that are expected before a review. I don't use here explicitly a mini-review because I want to let it clear that the whole library would be under review and I will hope that we will have some deep reviews, not only for the documentation but also the implementation and the tests. My decision has already been taken and I don't see any reason to change it. Vicente
On Thursday, 19 May 2016 21:03:35 MSK Vicente J. Botet Escriba wrote:
Not exactly. As Giovanni has explained, a conditional acceptance means something different than rejecting the library. We have identified during the review a lot of points Paul is already taking care of. Most of them concerns the documentation, some the design, and not too much the implementation. The issues that must be fixed are most of them already reported in github. I have not identified any issue that couldn't be managed. What is missing is a report to the fixes that are expected before a review. I don't use here explicitly a mini-review because I want to let it clear that the whole library would be under review and I will hope that we will have some deep reviews, not only for the documentation but also the implementation and the tests.
My decision has already been taken and I don't see any reason to change it.
Not to judge your decision, but what you described above sounds like the library should have been rejected (for a followup resubmission with a subsequent full review). 'Conditionally accepted' typically means the library is mostly ok to enter Boost, with a few issues that have to be fixed prior to that. A followup mini-review is typically for checking that those few points were fixed since the full review. Naturally, those conditions for acceptance need to be announced at the end of the full review (otherwise I don't see how they can be fixed or verified). Note that rejecting a library does not mean it's not useful or that it will never enter Boost. It merely means it will not enter at the point of this review.
On 19/05/2016 20:57, Vicente J. Botet Escriba wrote:
Does that not convey your intent well, including encouraging Paul to finish the task, without being contradictory like your formulation?
Not exactly. As Giovanni has explained, a conditional acceptance means something different than rejecting the library. We have identified during the review a lot of points Paul is already taking care of. Most of them concerns the documentation, some the design, and not too much the implementation. The issues that must be fixed are most of them already reported in github. I have not identified any issue that couldn't be managed. What is missing is a report to the fixes that are expected before a review. I don't use here explicitly a mini-review because I want to let it clear that the whole library would be under review and I will hope that we will have some deep reviews, not only for the documentation but also the implementation and the tests.
My decision has already been taken and I don't see any reason to change it.
I'd agree with Andrey here. Per http://www.boost.org/community/reviews.html#Results a library can either be rejected or accepted, and it the latter case a list conditions for final acceptance can be specified. Sometimes, we do have a mini-review to check those conditions. However, it seems that "accepted subject to another full review" is a tad inconsistent. Do you think you could make your final review result explicitly list those and only those issues that must be addressed before the library is included, such that those issues can be reasonably rechecked without 10-day full review? Thanks, -- Vladimir Prus http://vladimirprus.com
Le 19/05/2016 à 20:40, Vladimir Prus a écrit :
On 19/05/2016 20:57, Vicente J. Botet Escriba wrote:
Does that not convey your intent well, including encouraging Paul to finish the task, without being contradictory like your formulation?
Not exactly. As Giovanni has explained, a conditional acceptance means something different than rejecting the library. We have identified during the review a lot of points Paul is already taking care of. Most of them concerns the documentation, some the design, and not too much the implementation. The issues that must be fixed are most of them already reported in github. I have not identified any issue that couldn't be managed. What is missing is a report to the fixes that are expected before a review. I don't use here explicitly a mini-review because I want to let it clear that the whole library would be under review and I will hope that we will have some deep reviews, not only for the documentation but also the implementation and the tests.
My decision has already been taken and I don't see any reason to change it.
I'd agree with Andrey here. Per
http://www.boost.org/community/reviews.html#Results
a library can either be rejected or accepted, and it the latter case a list conditions for final acceptance can be specified. Sometimes, we do have a mini-review to check those conditions. However, it seems that "accepted subject to another full review" is a tad inconsistent.
Do you think you could make your final review result explicitly list those and only those issues that must be addressed before the library is included, such that those issues can be reasonably rechecked without 10-day full review?
Seen the reactions that I'm seen in this thread, I start to think that maybe I could be wrong with my decision. Before reconsidering it I would like to know how this is different of what happened with Boost.Fiber? The review was accepted conditionally twice. It seems to me that the list of conditions for the first conditional acceptance couldn't be checked without a 10-day full review period. What this is different compared with the Fit review? That I have not reported the list of issues to consider in this ML? That I have requested a full-review instead of a mini-review? If these are the cases, we could forget that I have taken my decision and I'll give it once I have the report. I could say that a mini-review is needed even if I believe that we need a full review, but this will not be honest from my part. I believe that we will need this 10-day review period if no more to review the revised Fit library. This is why I'm talking of the need of a full review. I don't consider to take time to review a library a bad thing as the first goal is for me to improve the library in all its aspects. If the Boost community considers that in these cases we should reject the library we should do the same in all the cases. Best, Vicente P.S. I have nothing against the Boost.Fiber library.
On Thu, May 19, 2016 at 7:07 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Seen the reactions that I'm seen in this thread, I start to think that maybe I could be wrong with my decision.
[snip]
I believe that we will need this 10-day review period if no more to review the revised Fit library. This is why I'm talking of the need of a full review. I don't consider to take time to review a library a bad thing as the first goal is for me to improve the library in all its aspects.
I did not observe the Fiber review, so I can't comment on that. I also agree with Andrey (and Vladimir and Robert)'s assessment: It seemed like your intention was a rejection (for this review) but that Paul was encouraged to address some of the issues raised, resubmit for a further review - which could carry a different result) This is probably because, as you've said, a full review of the library would be required. Glen
On May 19, 2016 7:58:51 PM EDT, Glen Fernandes <glen.fernandes@gmail.com> wrote:
Seen the reactions that I'm seen in this thread, I start to think
On Thu, May 19, 2016 at 7:07 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote: that maybe
I could be wrong with my decision.
[snip]
I believe that we will need this 10-day review period if no more to review the revised Fit library. This is why I'm talking of the need of a full review. I don't consider to take time to review a library a bad thing as the first goal is for me to improve the library in all its aspects.
I did not observe the Fiber review, so I can't comment on that. I also agree with Andrey (and Vladimir and Robert)'s assessment: It seemed like your intention was a rejection (for this review) but that Paul was encouraged to address some of the issues raised, resubmit for a further review - which could carry a different result)
This is probably because, as you've said, a full review of the library would be required.
Conditional acceptance has always meant that a library will be accepted once specific criteria, enumerated in the review summary, are met. A mini-review always followed to verify satisfaction of those criteria. If the library design, scope, or implementation must be subjected to further review, then the library is not acceptable, as is, for acceptance. In that case, it should be rejected. Like Glen, I don't know (or recall) what happened with the Fiber review. The only mention I found immediately was Nat's summary[1]. If the Fiber review was not handled consistent with what I just described, we could revisit that, but note that there was one enthusiastic "yes" vote for that library (from Niall). I infer that Nat was, himself, in favor of the library once it satisfied the criteria he listed. The result was conditional acceptance and a mini review to follow. It seems justified, though the paucity of reviews casts a little doubt on it. If you can produce a specific last of concrete criteria that Fit must meet such that it should be accepted automatically upon satisfying those criteria, then conditional acceptance is the appropriate result. If the list is extensive, but does not include open-ended changes, like redesigning a class hierarchy, sweeping API changes, etc., then the only question is how much time you think should be allotted to the mini review to be able to verify that the required changes have been made. ___ Rob [1] http://lists.boost.org/boost-announce/2015/10/0456.php (Sent from my portable computation engine)
Le 20/05/2016 à 10:39, Rob Stewart a écrit :
On May 19, 2016 7:58:51 PM EDT, Glen Fernandes <glen.fernandes@gmail.com> wrote:
Seen the reactions that I'm seen in this thread, I start to think
On Thu, May 19, 2016 at 7:07 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote: that maybe
I could be wrong with my decision.
I believe that we will need this 10-day review period if no more to review the revised Fit library. This is why I'm talking of the need of a full review. I don't consider to take time to review a library a bad thing as the first goal is for me to improve the library in all its aspects. I did not observe the Fiber review, so I can't comment on that. I also agree with Andrey (and Vladimir and Robert)'s assessment: It seemed
[snip] like your intention was a rejection (for this review) but that Paul was encouraged to address some of the issues raised, resubmit for a further review - which could carry a different result)
This is probably because, as you've said, a full review of the library would be required. Conditional acceptance has always meant that a library will be accepted once specific criteria, enumerated in the review summary, are met. A mini-review always followed to verify satisfaction of those criteria. If the library design, scope, or implementation must be subjected to further review, then the library is not acceptable, as is, for acceptance. In that case, it should be rejected.
Like Glen, I don't know (or recall) what happened with the Fiber review. The only mention I found immediately was Nat's summary[1]. If the Fiber review was not handled consistent with what I just described, we could revisit that, but note that there was one enthusiastic "yes" vote for that library (from Niall). I infer that Nat was, himself, in favor of the library once it satisfied the criteria he listed. The result was conditional acceptance and a mini review to follow. It seems justified, though the paucity of reviews casts a little doubt on it.
If you can produce a specific last of concrete criteria that Fit must meet such that it should be accepted automatically upon satisfying those criteria, then conditional acceptance is the appropriate result. If the list is extensive, but does not include open-ended changes, like redesigning a class hierarchy, sweeping API changes, etc., then the only question is how much time you think should be allotted to the mini review to be able to verify that the required changes have been made.
I don't want to precipitate on my decision. Do you believe that it would be better to withdraw my review result "Conditional acceptance (a new review is needed) " and let me the time to reconsider it once I have a complete report? Best, Vicente
On May 20, 2016 7:22:22 AM EDT, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote:
I don't want to precipitate on my decision. Do you believe that it would be better to withdraw my review result "Conditional acceptance (a new review is needed) " and let me the time to reconsider it once I have a complete report?
Paul is in limbo no matter what you do until your final result is posted. The only change rescinding your preliminary result would trigger is to deny Paul the right to claim that his library has been conditionally accepted, but that might be off-putting to Paul. I suggest leaving things as they are, with everyone recognizing that the outcome is unknown. Formally rescinding the preliminary result risks more harm than good at this point. ___ Rob (Sent from my portable computation engine)
On 5/20/16 5:05 AM, Rob Stewart wrote:
On May 20, 2016 7:22:22 AM EDT, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote:
I don't want to precipitate on my decision. Do you believe that it would be better to withdraw my review result "Conditional acceptance (a new review is needed) " and let me the time to reconsider it once I have a complete report?
Paul is in limbo no matter what you do until your final result is posted. The only change rescinding your preliminary result would trigger is to deny Paul the right to claim that his library has been conditionally accepted, but that might be off-putting to Paul.
I suggest leaving things as they are, with everyone recognizing that the outcome is unknown. Formally rescinding the preliminary result risks more harm than good at this point.
Agreed. Just leave everything in suspended animation until you make the final report. Note to future reviewers: Reveal whole review or nothing at all. Your life will be easier. Robert Ramey
Robert Ramey wrote:
Agreed.
Just leave everything in suspended animation until you make the final report.
Note to future reviewers: Reveal whole review or nothing at all. Your life will be easier.
*Nod*. Is the AFIO review taking the "or nothing at all" route, then? Glen -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Fit-review-Mars-3-20-result-tp46850... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 5/20/16 9:17 AM, Glen Fernandes wrote:
Robert Ramey wrote:
Agreed.
Just leave everything in suspended animation until you make the final report.
Note to future reviewers: Reveal whole review or nothing at all. Your life will be easier.
*Nod*.
Is the AFIO review taking the "or nothing at all" route, then?
I think that's a whole 'nuther question. The review wizard should chase this down and bug the reviewer for some sort of official resolution to the status. Robert Ramey
On May 20, 2016, at 10:30 AM, Robert Ramey <ramey@rrsd.com> wrote:
On 5/20/16 9:17 AM, Glen Fernandes wrote:
Robert Ramey wrote:
Agreed.
Just leave everything in suspended animation until you make the final report.
Note to future reviewers: Reveal whole review or nothing at all. Your life will be easier.
*Nod*.
Is the AFIO review taking the "or nothing at all" route, then?
I think that's a whole 'nuther question. The review wizard should chase this down and bug the reviewer for some sort of official resolution to the status.
Already done. Ideally you should see some movement on this soon. Best, Ron
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 5/20/16 11:14 AM, Ronald Garcia wrote:
On May 20, 2016, at 10:30 AM, Robert Ramey <ramey@rrsd.com> wrote:
On 5/20/16 9:17 AM, Glen Fernandes wrote:
Robert Ramey wrote:
Agreed.
Just leave everything in suspended animation until you make the final report.
Note to future reviewers: Reveal whole review or nothing at all. Your life will be easier.
*Nod*.
Is the AFIO review taking the "or nothing at all" route, then?
I think that's a whole 'nuther question. The review wizard should chase this down and bug the reviewer for some sort of official resolution to the status.
Already done. Ideally you should see some movement on this soon.
I just wanted to take the opportunity to note what a great job you've done over the last 13? years. I know you're going to say it's not a huge job it's not that time consuming its not a big deal, etc. BUT it is a big and important job. The fact that you get on it and keep it up to date makes it (look?) easy. If you didn't do this as well as you do, we'd have yet another rolling fiasco on our hands. Ironies of ironies, the better job one does, the easier it is made to look and the less it's appreciated. Not fair, but still better than constant excuses, complaints and other drama. If more people did as you do, we'd be better off. Robert Ramey
Best, Ron
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On May 20, 2016, at 6:22 PM, Robert Ramey <ramey@rrsd.com> wrote:
On 5/20/16 11:14 AM, Ronald Garcia wrote:
Is the AFIO review taking the "or nothing at all" route, then?
I think that's a whole 'nuther question. The review wizard should chase this down and bug the reviewer for some sort of official resolution to the status.
Already done. Ideally you should see some movement on this soon.
I just wanted to take the opportunity to note what a great job you've done over the last 13? years. I know you're going to say it's not a huge job it's not that time consuming its not a big deal, etc.
BUT it is a big and important job. The fact that you get on it and keep it up to date makes it (look?) easy. If you didn't do this as well as you do, we'd have yet another rolling fiasco on our hands. Ironies of ironies, the better job one does, the easier it is made to look and the less it's appreciated. Not fair, but still better than constant excuses, complaints and other drama. If more people did as you do, we'd be better off.
Robert Ramey
Thanks a lot Robert. I should of course note that it’s not just me: John Phillips has been co-wizard for almost all of that time. It’s a team effort. Much appreciated! Ron
On 20 May 2016 at 11:14, Ronald Garcia wrote:
Is the AFIO review taking the "or nothing at all" route, then?
I think that's a whole 'nuther question. The review wizard should chase this down and bug the reviewer for some sort of official resolution to the status.
Already done. Ideally you should see some movement on this soon.
In case you need to know, I took the review as a likely rejection and have begun the process of redesiging and rewriting the thing from scratch based on my best synthesis of the review feedback. AFIO v2 docs can be found at https://ned14.github.io/boost.afio/index.html I expect it to be ready for review around 2018. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Le 20/05/2016 à 14:05, Rob Stewart a écrit :
On May 20, 2016 7:22:22 AM EDT, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote:
I don't want to precipitate on my decision. Do you believe that it would be better to withdraw my review result "Conditional acceptance (a new review is needed) " and let me the time to reconsider it once I have a complete report? Paul is in limbo no matter what you do until your final result is posted. The only change rescinding your preliminary result would trigger is to deny Paul the right to claim that his library has been conditionally accepted, but that might be off-putting to Paul.
I suggest leaving things as they are, with everyone recognizing that the outcome is unknown. Formally rescinding the preliminary result risks more harm than good at this point.
Thank for your advice, Vicente
participants (11)
-
Andrey Semashev -
Giovanni Piero Deretta -
Glen Fernandes -
Niall Douglas -
P F -
Paul Fultz II
-
Rob Stewart -
Robert Ramey -
Ronald Garcia -
Vicente J. Botet Escriba -
Vladimir Prus