It's not. We do a lot of code review, and it's done publicly. It's easy to look at the commit logs. I find it telling that the article doesn't spend even one word trying to delve into our code review practices. This case was an aberration.
This defensiveness in FreeBSD's response, this reaction of minimizing rather than facing up to the seriousness of the problem revealed here, the attempt to redirect the conversation towards anything but the specific issue, only reinforces the impression that FreeBSD may not be ready to deal with it effectively.
Of course, as FreeBSD is open source, its users are in no position to demand anything, but any potential user may, and should, attempt to determine how likely it is meet her needs in all respects.
Has there been any discussion about why the process failed in this case, and what is going to be done to make sure something similar doesn't happen in the future?
This is the review for the original commit, in case anyone is interested: https://reviews.freebsd.org/D26137
“Neither Netgate's responses, FreeBSD Core's, nor the off-record responses we heard from independent FreeBSD community members lead us to believe that there was in fact any process in place that could reasonably have been expected to catch this issue prior to it going out into the world in 13.0-RELEASE”
But it would help if he made it clear why he felt this criticism was specific to FreeBSD release13. It sounds to a naive reader like a critique that could apply to much of open source software. The author didn’t say that, but it’s a reasonable extrapolation to make.
> The article starts as a gotcha piece
Haha, that’s the problem. You, Netapp, value saving face so very much that you are incapable of constructive response to well-meaning, fair, and honest criticism.
“you either have a commit bit (enabling you to commit code to FreeBSD's repositories) or you don't. It's hard to find code reviews, and there generally isn't a fixed process ensuring that vitally important code gets reviewed prior to inclusion. This system thus relies heavily on the ability and collegiality of individual code creators.”
From my perspective, this whole thing is due to a severe failure of the development process. The sub-standard code should never have been committed. But if there is no process, is it really a failure? Or is this just how it is on FreeBSD?