From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2020-10-09 15:34:10
pt., 9 paÅº 2020 o 17:22 Robert Ramey via Boost <boost_at_[hidden]>
> On 10/8/20 9:28 PM, Andrzej Krzemienski via Boost wrote:
> > czw., 8 paÅº 2020 o 19:18 Robert Ramey via Boost <boost_at_[hidden]>
> > 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
> > 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 (
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;
> > _______________________________________________
> > Unsubscribe & other changes:
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk