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