Boost.Fit review Mars 3-20 result

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Boost.Fit review Mars 3-20 result

Vicente Botet
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




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Robert Ramey
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Paul Fultz II

> On Apr 3, 2016, at 11:19 AM, Robert Ramey <[hidden email]> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Robert Ramey
On 4/3/16 9:56 AM, P F wrote:

>
>> On Apr 3, 2016, at 11:19 AM, Robert Ramey <[hidden email]> 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




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Robert Ramey
In reply to this post by Vicente Botet
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Paul Fultz II

> On May 17, 2016, at 11:29 PM, Robert Ramey <[hidden email]> 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).




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Rob Stewart-2
On May 18, 2016 12:52:06 AM EDT, Paul Fultz II <[hidden email]> wrote:

>
>> On May 17, 2016, at 11:29 PM, Robert Ramey <[hidden email]> 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)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Vicente Botet
Le 18/05/2016 à 10:29, Rob Stewart a écrit :

> On May 18, 2016 12:52:06 AM EDT, Paul Fultz II <[hidden email]> wrote:
>>> On May 17, 2016, at 11:29 PM, Robert Ramey <[hidden email]> 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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Robert Ramey
> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Rob Stewart-2
In reply to this post by Vicente Botet
On May 18, 2016 2:18:16 PM EDT, "Vicente J. Botet Escriba" <[hidden email]> wrote:

>Le 18/05/2016 à 10:29, Rob Stewart a écrit :
>> On May 18, 2016 12:52:06 AM EDT, Paul Fultz II <[hidden email]>
>wrote:
>>>> On May 17, 2016, at 11:29 PM, Robert Ramey <[hidden email]> 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)
>>>>
>>>> Given the text I snipped, I don't see how one could characterize
>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)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Giovanni Piero Deretta
On 19 May 2016 2:04 a.m., "Rob Stewart" <[hidden email]> wrote:
>
> On May 18, 2016 2:18:16 PM EDT, "Vicente J. Botet Escriba" <
[hidden email]> wrote:

> >Le 18/05/2016 à 10:29, Rob Stewart a écrit :
> >> On May 18, 2016 12:52:06 AM EDT, Paul Fultz II <[hidden email]>
> >wrote:
> >>>> On May 17, 2016, at 11:29 PM, Robert Ramey <[hidden email]> 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)
> >>>>
> >>>> Given the text I snipped, I don't see how one could characterize
> >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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Vicente Botet
In reply to this post by Rob Stewart-2
Le 19/05/2016 à 03:04, Rob Stewart a écrit :

> On May 18, 2016 2:18:16 PM EDT, "Vicente J. Botet Escriba" <[hidden email]> wrote:
>> Le 18/05/2016 à 10:29, Rob Stewart a écrit :
>>> On May 18, 2016 12:52:06 AM EDT, Paul Fultz II <[hidden email]>
>> wrote:
>>>>> On May 17, 2016, at 11:29 PM, Robert Ramey <[hidden email]> 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)
>>>>> Given the text I snipped, I don't see how one could characterize
>> 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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Andrey Semashev-2
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Vladimir Prus-4
In reply to this post by Vicente Botet
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Vicente Botet
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Glen Fernandes
On Thu, May 19, 2016 at 7:07 PM, Vicente J. Botet Escriba
<[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Rob Stewart-2
On May 19, 2016 7:58:51 PM EDT, Glen Fernandes <[hidden email]> wrote:

>On Thu, May 19, 2016 at 7:07 PM, Vicente J. Botet Escriba
><[hidden email]> 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.

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)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Vicente Botet
Le 20/05/2016 à 10:39, Rob Stewart a écrit :

> On May 19, 2016 7:58:51 PM EDT, Glen Fernandes <[hidden email]> wrote:
>> On Thu, May 19, 2016 at 7:07 PM, Vicente J. Botet Escriba
>> <[hidden email]> 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.
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Rob Stewart-2
On May 20, 2016 7:22:22 AM EDT, "Vicente J. Botet Escriba" <[hidden email]> 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)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Fit review Mars 3-20 result

Robert Ramey
On 5/20/16 5:05 AM, Rob Stewart wrote:

> On May 20, 2016 7:22:22 AM EDT, "Vicente J. Botet Escriba" <[hidden email]> 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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12