Re: [Boost] [PFR][review] Result

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [PFR][review] Result

Boost - Dev mailing list
On Thu, 8 Oct 2020 at 12:51, Benedek Thaler via Boost
<[hidden email]> wrote:
>
> Thanks to all of you who participated in the formal review of PFR,
> henceforth known as Boost.PFR, and Antony Polukhin for submitting this
> magical library.

Benedek,

Thank you for your act as the review manager.

> PFR is ACCEPTed into Boost, with the following results:
>
> ACCEPT: 5 votes
> CONDITIONAL ACCEPT: 1 vote
> REJECT: 0 votes
>
> After all these changes have been implemented, Antony would really
> like to have a mini-review, regardless that the library is already
> ACCEPTed, further confirming his high standards.

Typically, mini-review is offered after a review
concludes with a "conditionally accepted" result.
Mini-review is to determine if the conditions have been met,
but that is not the case here.

I'm not experienced with mini-review, yet,
so I'd like to clarify the situation and the steps to follow:

1. PFR is accepted
2. Antony wants to postpone inclusion of PFR in Boost
3. Antony is going to request mini-review
4. Benedek will act as the manager of the mini-review
5. If the reviewers confirm the changes have been implemented,
    the library will be included in Boost.
   Otherwise, Antony continues until planned changes are applied,
    then we run another mini-review

Antony, is that what you aim for?

Why not just include the PFR in Boost now,
then continue applying the changes you have planned,
then merge to master in order to release
If necessary, I think, you can request a mini-review to ask
reviewers if the PFR is ready for release.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

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

Re: [Boost] [PFR][review] Result

Boost - Dev mailing list
Mateusz Loskot wrote:

> Why not just include the PFR in Boost now, then continue applying the
> changes you have planned, then merge to master in order to release
>
> If necessary, I think, you can request a mini-review to ask reviewers if
> the PFR is ready for release.

A reminder that the cutoff date for new libraries is Oct 21.


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

Re: [Boost] [PFR][review] Result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, Oct 8, 2020 at 5:36 PM Mateusz Loskot <[hidden email]> wrote:

>
> On Thu, 8 Oct 2020 at 12:51, Benedek Thaler via Boost
> <[hidden email]> wrote:
> >
>
> > PFR is ACCEPTed into Boost, with the following results:
> >
> > ACCEPT: 5 votes
> > CONDITIONAL ACCEPT: 1 vote
> > REJECT: 0 votes
> >
> > After all these changes have been implemented, Antony would really
> > like to have a mini-review, regardless that the library is already
> > ACCEPTed, further confirming his high standards.
>
> Typically, mini-review is offered after a review
> concludes with a "conditionally accepted" result.
> Mini-review is to determine if the conditions have been met,
> but that is not the case here.
>
> I'm not experienced with mini-review, yet,
> so I'd like to clarify the situation and the steps to follow:
>
> 1. PFR is accepted
> 2. Antony wants to postpone inclusion of PFR in Boost
> 3. Antony is going to request mini-review
> 4. Benedek will act as the manager of the mini-review
> 5. If the reviewers confirm the changes have been implemented,
>     the library will be included in Boost.
>    Otherwise, Antony continues until planned changes are applied,
>     then we run another mini-review
>
> Antony, is that what you aim for?
>
> Why not just include the PFR in Boost now,
> then continue applying the changes you have planned,
> then merge to master in order to release
> If necessary, I think, you can request a mini-review to ask
> reviewers if the PFR is ready for release.
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net

Perhaps my use of the term "mini-review" was confusing.
PFR is ACCEPTed, therefore the formal process was concluded.
After a library is accepted, it typically takes time to adjust the
library to the boost infrastructure,
and to address comments (without addressing the comments, there's no
point requiring detailed reviews).
Antony is transparent regarding the planned changes,
and would like to hear the opinion of those who were interested,
after those changes have been made - in the form of a non-mini-review.
(it is not part of the formal process, so there's no formal name of this event)

Benedek

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

Re: [Boost] [PFR][review] Result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/8/20 8:38 AM, Mateusz Loskot via Boost wrote:

> On Thu, 8 Oct 2020 at 12:51, Benedek Thaler via Boost
> <[hidden email]> wrote:
>>
>> Thanks to all of you who participated in the formal review of PFR,
>> henceforth known as Boost.PFR, and Antony Polukhin for submitting this
>> magical library.
>
> Benedek,
>
> Thank you for your act as the review manager.
>
>> PFR is ACCEPTed into Boost, with the following results:
>>
>> ACCEPT: 5 votes
>> CONDITIONAL ACCEPT: 1 vote
>> REJECT: 0 votes
>>
>> After all these changes have been implemented, Antony would really
>> like to have a mini-review, regardless that the library is already
>> ACCEPTed, further confirming his high standards.

I think the custom has been:

1. reviewer accepts the library.
2. usually subject to some conditions.
3. the final version with the conditions met is merged into boost.

Boost rules don't require that a library be in "finished form" to be
reviewed.  The author should submit enough working implementation so a
decision can be arrived at.  The motivation is to make library
submission no more onerous then necessary.  As far as I know, we haven'
t had a formal requirement for review of the final product.
Intuitively, I would think there should be such a requirement, but
really, it hasn't seemed necessary.

Sooo - I would say anthony should just finish up the library in a way
which addresses the review managers conditions. If he want's to have
someone comment on the "final" version, he can just ask.
Then merge it into the boost develop branch.

As author of two boost libraries, I can offer a little perspective.

My first submission back in 2003 was the boost serialization library.
Many people found fault with it and it soundly rejected after "spirited"
discussion.  I then re did it and submitted it again a year later.  (I
am a glutton for punishment). I was accepted and eventually incorporated
into boost.

My second offering is the safe numerics library. It had some loose ends
but was considered sufficiently implemented to accept. And so it was.
Apparently, it was not that interesting for enough people to craft
objections to.  WHat happened next?

You guessed it.  cleaning up the "loose ends", unraveled the whole
library implementation.  Even worse, it impacted that type requirements
(concepts) which the library specified.  It was almost like starting
from scratch again. About the only thing left unscathed was the
documentation. When I got it back together, I merged into boost
development branch.  .... and the it is.  No one objected to this.  In
fact, no one even noticed. Did I do the right thing? Should I have asked
for another review?  You decide.  I'm wondering if it got accepted in
large part due the documentation.  As usual, I don't have point here -
just like to keep the pot boiling.

Robert Ramey


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

Re: [Boost] [PFR][review] Result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, 8 Oct 2020 at 18:57, Peter Dimov via Boost
<[hidden email]> wrote:
> Mateusz Loskot wrote:
>
> > Why not just include the PFR in Boost now, then continue applying the
> > changes you have planned, then merge to master in order to release
> >
> > If necessary, I think, you can request a mini-review to ask reviewers if
> > the PFR is ready for release.
>
> A reminder that the cutoff date for new libraries is Oct 21.

Yes, I just left the release cycle unspecified.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

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

[safe_numerics] needs a mini-review

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
czw., 8 paź 2020 o 19:18 Robert Ramey via Boost <[hidden email]>
napisał(a):

>
> As author of two boost libraries, I can offer a little perspective.
>
> My second offering is the safe numerics library. It had some loose ends
> but was considered sufficiently implemented to accept. And so it was.
> Apparently, it was not that interesting for enough people to craft
> objections to.  WHat happened next?
>
> You guessed it.  cleaning up the "loose ends", unraveled the whole
> library implementation.  Even worse, it impacted that type requirements
> (concepts) which the library specified.  It was almost like starting
> from scratch again. About the only thing left unscathed was the
> documentation. When I got it back together, I merged into boost
> development branch.  .... and the it is.  No one objected to this.  In
> fact, no one even noticed. Did I do the right thing? Should I have asked
> for another review?  You decide.  I'm wondering if it got accepted in
> large part due the documentation.  As usual, I don't have point here -
> just like to keep the pot boiling.
>

The review result of Safe Numerics library was that it is conditionally
accepted:
https://lists.boost.org/Archives/boost/2017/03/233511.php

My understanding of the process is that as the next steps:
1. The author applies the indicated conditions and reports readiness for a
mini-review.
2. A mini-review is scheduled. Its purpose is to determine if the
conditions have been satisfied
3. If the review passes, the author has green light to release their
library as part of Boost libraries.

I read your message as saying that safe_numerics is ready for a
mini-review. Is that correct?

Regards,
&rzej;

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

Re: [Boost] [PFR][review] Result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, Oct 8, 2020, 20:18 Robert Ramey via Boost <[hidden email]>
wrote:
<...>

> Sooo - I would say anthony should just finish up the library in a way
> which addresses the review managers conditions. If he want's to have
> someone comment on the "final" version, he can just ask.
> Then merge it into the boost develop branch.
>

Yep, soonds good. I take this option

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

Re: [Boost] [PFR][review] Result

Boost - Dev mailing list
On Fri, 9 Oct 2020 at 08:42, Antony Polukhin via Boost
<[hidden email]> wrote:

> On Thu, Oct 8, 2020, 20:18 Robert Ramey via Boost <[hidden email]> wrote:
> <...>
>
> > Sooo - I would say anthony should just finish up the library in a way
> > which addresses the review managers conditions. If he want's to have
> > someone comment on the "final" version, he can just ask.
> > Then merge it into the boost develop branch.
> >
>
> Yep, soonds good. I take this option

Antony, great.

Robert, thank you too.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

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

Re: [Boost] [PFR][review] Result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, 8 Oct 2020 at 19:05, Benedek Thaler <[hidden email]> wrote:

> On Thu, Oct 8, 2020 at 5:36 PM Mateusz Loskot <[hidden email]> wrote:
> > On Thu, 8 Oct 2020 at 12:51, Benedek Thaler via Boost <[hidden email]> wrote:
> > >
> > > PFR is ACCEPTed into Boost, with the following results:
> > >
> > > ACCEPT: 5 votes
> > > CONDITIONAL ACCEPT: 1 vote
> > > REJECT: 0 votes
> > >
> > > After all these changes have been implemented, Antony would really
> > > like to have a mini-review, regardless that the library is already
> > > ACCEPTed, further confirming his high standards.
> >
> > Typically, mini-review is offered after a review
> > concludes with a "conditionally accepted" result.
> > Mini-review is to determine if the conditions have been met,
> > but that is not the case here.
> > [...]
>
> Perhaps my use of the term "mini-review" was confusing.
> PFR is ACCEPTed, therefore the formal process was concluded.
> After a library is accepted, it typically takes time to adjust the
> library to the boost infrastructure,
> and to address comments (without addressing the comments, there's no
> point requiring detailed reviews).
> Antony is transparent regarding the planned changes,
> and would like to hear the opinion of those who were interested,
> after those changes have been made - in the form of a non-mini-review.
> (it is not part of the formal process, so there's no formal name of this event)

Thanks for the clarification.

All my questions have been answered.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

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

Re: [safe_numerics] needs a mini-review

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/8/20 9:28 PM, Andrzej Krzemienski via Boost wrote:

> czw., 8 paź 2020 o 19:18 Robert Ramey via Boost <[hidden email]>
> napisał(a):
>
>>
>> As author of two boost libraries, I can offer a little perspective.
>>
>> My second offering is the safe numerics library. It had some loose ends
>> but was considered sufficiently implemented to accept. And so it was.
>> Apparently, it was not that interesting for enough people to craft
>> objections to.  WHat happened next?
>>
>> You guessed it.  cleaning up the "loose ends", unraveled the whole
>> library implementation.  Even worse, it impacted that type requirements
>> (concepts) which the library specified.  It was almost like starting
>> from scratch again. About the only thing left unscathed was the
>> documentation. When I got it back together, I merged into boost
>> development branch.  .... and the it is.  No one objected to this.  In
>> fact, no one even noticed. Did I do the right thing? Should I have asked
>> for another review?  You decide.  I'm wondering if it got accepted in
>> large part due the documentation.  As usual, I don't have point here -
>> just like to keep the pot boiling.
>>
>
> The review result of Safe Numerics library was that it is conditionally
> accepted:
> https://lists.boost.org/Archives/boost/2017/03/233511.php
>
> My understanding of the process is that as the next steps:
> 1. The author applies the indicated conditions and reports readiness for a
> mini-review.
> 2. A mini-review is scheduled. Its purpose is to determine if the
> conditions have been satisfied
> 3. If the review passes, the author has green light to release their
> library as part of Boost libraries.

Of course this is the question at hand right now.  If there are
conditions, how should the be enforced?  In many/most cases the
conditions are pretty simple and straight forward so one has confidence
that the author will simply make the updates and check in the library.
I believe that this is the most common case.

But sometimes, even though the conditions might seem straight forward,
implementing them might end up being a lot more work than first meets
the eye.  In the case of safe numerics, I did manage (in my personal
estimation) to implement all the stated conditions, but the effort
required to do so was far beyond what I had anticipated.  I also ended
up refining ideas which were actually incorrect but never detected/noted
in the review.  I fixed that stuff also.

So to my mind, the system worked well and as intended.

a) I made the prototype library including documentation and carefully
specified API
b) It got reviewed
c) It got accepted subject to some conditions
d) I re-implemented it to fulfill all the conditions, fix discovered
mistakes, fill in missing pieces.
f) checked it in.

The "missing step" would be e) - get a mini-review.  Honestly this just
never occurred to me.  I had included all the conditions as issues on
github and documented my changes there so I'm pretty confident that I
addressed them all.  I probably should have asked you to verify/certify
that the conditions were met.  But it didn't occur to me.

In short, I'm arguing that a "mini-review" is generally not necessary
and I don't think it's documented as as a step in the boost "process".

>
> I read your message as saying that safe_numerics is ready for a
> mini-review. Is that correct?
>
In this particular case, I'd be happy to respond to anyone who wants to
subject the current version of the safe numerics library to a
mini-review.  In general, I love talking about my stuff.

> Regards,
> &rzej;
>
> _______________________________________________
> 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: [safe_numerics] needs a mini-review

Boost - Dev mailing list
pt., 9 paź 2020 o 17:22 Robert Ramey via Boost <[hidden email]>
napisał(a):

> On 10/8/20 9:28 PM, Andrzej Krzemienski via Boost wrote:
> > czw., 8 paź 2020 o 19:18 Robert Ramey via Boost <[hidden email]>
> > napisał(a):
> >
> >>
> >> As author of two boost libraries, I can offer a little perspective.
> >>
> >> My second offering is the safe numerics library. It had some loose ends
> >> but was considered sufficiently implemented to accept. And so it was.
> >> Apparently, it was not that interesting for enough people to craft
> >> objections to.  WHat happened next?
> >>
> >> You guessed it.  cleaning up the "loose ends", unraveled the whole
> >> library implementation.  Even worse, it impacted that type requirements
> >> (concepts) which the library specified.  It was almost like starting
> >> from scratch again. About the only thing left unscathed was the
> >> documentation. When I got it back together, I merged into boost
> >> development branch.  .... and the it is.  No one objected to this.  In
> >> fact, no one even noticed. Did I do the right thing? Should I have asked
> >> for another review?  You decide.  I'm wondering if it got accepted in
> >> large part due the documentation.  As usual, I don't have point here -
> >> just like to keep the pot boiling.
> >>
> >
> > The review result of Safe Numerics library was that it is conditionally
> > accepted:
> > https://lists.boost.org/Archives/boost/2017/03/233511.php
> >
> > My understanding of the process is that as the next steps:
> > 1. The author applies the indicated conditions and reports readiness for
> a
> > mini-review.
> > 2. A mini-review is scheduled. Its purpose is to determine if the
> > conditions have been satisfied
> > 3. If the review passes, the author has green light to release their
> > library as part of Boost libraries.
>
> Of course this is the question at hand right now.  If there are
> conditions, how should the be enforced?  In many/most cases the
> conditions are pretty simple and straight forward so one has confidence
> that the author will simply make the updates and check in the library.
> I believe that this is the most common case.
>
> But sometimes, even though the conditions might seem straight forward,
> implementing them might end up being a lot more work than first meets
> the eye.  In the case of safe numerics, I did manage (in my personal
> estimation) to implement all the stated conditions, but the effort
> required to do so was far beyond what I had anticipated.  I also ended
> up refining ideas which were actually incorrect but never detected/noted
> in the review.  I fixed that stuff also.
>
> So to my mind, the system worked well and as intended.
>
> a) I made the prototype library including documentation and carefully
> specified API
> b) It got reviewed
> c) It got accepted subject to some conditions
> d) I re-implemented it to fulfill all the conditions, fix discovered
> mistakes, fill in missing pieces.
> f) checked it in.
>
> The "missing step" would be e) - get a mini-review.  Honestly this just
> never occurred to me.  I had included all the conditions as issues on
> github and documented my changes there so I'm pretty confident that I
> addressed them all.  I probably should have asked you to verify/certify
> that the conditions were met.  But it didn't occur to me.
>
> In short, I'm arguing that a "mini-review" is generally not necessary
> and I don't think it's documented as as a step in the boost "process".
>

Yes, you are correct. Our policy (
https://www.boost.org/community/reviews.html) says:

If a review results in conditions on acceptance, the review manager may
> request a Mini-Review to determine if the conditions have been met. The
> Mini-Review is usually conducted by the same review manager.
>

The review manager (that is, me) never requested a mini-review, so you were
under no obligation to undergo one. My apologies for claiming the opposite.
I somehow believed that declaring a conditional acceptance implies a
request for a mini-review, but this is not the case.


> >
> > I read your message as saying that safe_numerics is ready for a
> > mini-review. Is that correct?
> >
> In this particular case, I'd be happy to respond to anyone who wants to
> subject the current version of the safe numerics library to a
> mini-review.  In general, I love talking about my stuff.
>

In that case, I commit to doing a private mini-review of safe_numerics :)

Regards,
&rzej;


> > Regards,
> > &rzej;
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
>
>
> _______________________________________________
> 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: [safe_numerics] needs a mini-review

Boost - Dev mailing list
On 10/9/20 8:34 AM, Andrzej Krzemienski via Boost wrote:

> In that case, I commit to doing a private mini-review of safe_numerics :)

Your feedback is always welcome.  Your "conditions" pointed to all the
stuff that need work. Without your work as review manager, I doubt that
the library would ever have been completed.

> Regards,
> &rzej;
>
>
>>> Regards,
>>> &rzej;
>>>
>>> _______________________________________________
>>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>>
>>
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>
> _______________________________________________
> 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: [safe_numerics] needs a mini-review

Boost - Dev mailing list
On 10/9/20 9:57 AM, Robert Ramey via Boost wrote:
> On 10/9/20 8:34 AM, Andrzej Krzemienski via Boost wrote:
>
>> In that case, I commit to doing a private mini-review of safe_numerics :)
>
> Your feedback is always welcome.  Your "conditions" pointed to all the
> stuff that need work. Without your work as review manager, I doubt that
> the library would ever have been completed.
>> Regards,
>> &rzej;

Hmmm - thinking about this a little more and going over the text of the
boost rules, (I'm a originalist and textualist), I would think that that
the review manager could include in his list of conditions that that the
library undergo a "mini-review" (whatever that might mean) before final
acceptance.  Soooo it looks like we've already got all cases covered: a
library which is already almost perfect and just needs a few tweaks is
just added in when the developer things he's done.  At the other hand,
some library which is more of a proof of concept, might be accepted
subject to a condition which says it needs a "mini-review".  No need
what so ever to mess with boost rules.

Robert Ramey

>>
>>
>>>> Regards,
>>>> &rzej;
>>>>
>>>> _______________________________________________
>>>> Unsubscribe & other changes:
>>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Unsubscribe & other changes:
>>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>>
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>



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