Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2020-10-09 15:21:54

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:
> 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at