Btw. great gathering of people with a *BSD background or friends :-)
I think, we all should be way more cool headed. Email doesn't contain the tone and it is very easy to formulate something in a bad way when exhausted or upset. Some people use very strong words that considering their usual style aren't nearly as strong in reality.
In this case, the great question is, how did such a bad code (according to Jason) land in the code base at all? Don't other people look at it? Do the FreeBSD developers ignore concerns of other fellow developers until it blows up to beyond community communication circles?
It makes sense to me. As I understand the FreeBSD mailing list posts, it was commissioned commercially, to add a feature to NetGate products.
Must have: in-kernel WireGuard for NetGate products.
Nice-to-have: a general-purpose FreeBSD kernel WireGuard.
The scope crept, and a piece of code that might have been fit for some purpose (whatever limitations NetGate has for its network stack, like "no jumbo frames", etc) was recast as fit for all purposes.
I guess Colin would have some insight about the process by which a ports-grade kernel module gets put on track for release in the kernel itself.
My take on this is that absolutely no part of the development process that led up to this is Jason's problem. It is not Jason's job to understand or assist or comply with NetGate's product development process; his concern seems to have been, justifiably, exclusively the proposed FreeBSD OS feature. I get the sense that a lot of the friction here comes from pfSense-types thinking that any part of pfSense is everyone's problem.
Thank you for the reply. Yes, I understand Jason is basically only involved as "I have looked at this thing you propose/ have in FreeBSD and I don't like what I see, let me improve/ discuss further plans".
My question basically is: "How is it possible, the code of such quality was even seriously included in a branch of FreeBSD that would have been released if nobody would step in?" (That is if I understand the whole thing correctly and Jason's assessment is correct.)
I also think, if you dedicate something like 5 years of your life solely to kernel C implementations of a single protocol, it's probably a lot easier for you to spot problems than it is for an arbitrary FreeBSD developer.
Short answer: With a very small number of exceptions, we trust FreeBSD developers to exercise good judgement in obtaining review and ensuring the quality of the code they commit. The FreeBSD project is selective in whom it gives commit bits to, and we have a mentoring process which further ensures that developers understand the norms.
This system isn't foolproof, but it generally works very well. There have been discussions about moving to a "mandatory review" model, but there is concern that this might overly slow down development in the context of a volunteer-run project.
