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.

On Thu, Oct 8, 2020 at 5:36 PM Mateusz Loskot wrote:

On Thu, 8 Oct 2020 at 12:51, Benedek Thaler via Boost 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

On 10/8/20 8:38 AM, Mateusz Loskot via Boost wrote:

On Thu, 8 Oct 2020 at 12:51, Benedek Thaler via Boost 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

On 10/8/20 9:28 PM, Andrzej Krzemienski via Boost wrote:

czw., 8 paź 2020 o 19:18 Robert Ramey via Boost 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

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

On Thu, Oct 8, 2020, 20:18 Robert Ramey via Boost 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