Reaction score: 1,675
Wait a minute... I thought we were the Goat.
Even if the initiative came that way (I can't verify) – you wouldn't sell that as the correct and safe procedure for such things? It was in -RC2, which is the final mandatory RC, so removing it thereafter was indeed the very latest possible moment. Luck is a factor, at least with this timing.At the risk of repeating myself, no luck was involved. Another Freebsd committer had misgivings about such a large commit with so little review and he sought and found help auditing it in the broader FOSS community.
Whatever this article does… the takeaway for FreeBSD isn't fingerpointing towards Macy. He obviously "failed" here, but no single failure should lead to a near-desaster in a release. So, just forget that article, it's bad style in many ways, but don't forget the incident, so it won't repeat.
Nope not as I understand it.No luck involved. Another Freebsd committer reached out to Donenfeld (lead author of Wireguard) with concerns about the implementation.
The two of them plus an Openbsd developer that worked on the Openbsd WG implementation then worked together to come up with an alternate implementation.
[...] This incident highlights the need to do this work more proactively, and to maintain a robust, multi-layered development process that can catch problems as they fall through the cracks. Over the next month the FreeBSD Core Team will lead a discussion on appropriate pre-commit testing, static analysis, code review, and integration policies to avoid a repeat of this situation and to continue improving FreeBSD's code quality. We know there will be challenges in key areas, such as third-party device drivers, and components of the system where fewer developers have sufficient expertise. The FreeBSD Foundation has full-time staff members participating in significant code review today, and is committed to supporting the needs identified by the Core team and the developer community for this effort. We look forward to input from the community on our proposals for updated policies as we move forward, maintaining high code quality as a core value for FreeBSD.
That would be great! But I'm more in favour of a department of inquisition.I'm not sure if I should seriously suggest to add an interview done by a team of professional, highly skilled psychologists to check the so-called soft skills, before granting a commit bit to a developer.
What kind of security clearance would a guy get who is in debt over both his ears, has proven that he has zero loyalty, zero sense of responsibility, would even (literally) sell his mother, is willing to do heinous crimes to satisfy his greed?Quality control of security-scale software needs more than what FreeBSD just showed for Wireguard.
Blaming s/o who's code is cluttered withThat would be great! But I'm more in favour of a department of inquisition.
#ifdef's and constraints unconditionally
return truehas nothing to do with inquisition. As noted above a few times, critical questions on Phabricator were simply ignored, as well as the offer to help by e-mail. IIRC the average LoC a developer writes is 8/day (!!!). 40 kLoC were commited in just a few month, meeting every notion of C's worst practices. All that together is just another proof of an obnoxious, yukky character. Period.
I welcome your critical mind, but I can't relate any of this to the issue. Please elaborate.I won't draw a conclusion, but I wonder which departments made ASA to issue this statement:
ASA: The ASA Statement on p-Values: Context, Process, and Purpose
APA: P-values under question
Nature: Scientists rise up against statistical significance
Nature: 1,500 scientists lift the lid on reproducibility
Nope not as I understand it.
Fortunately, two weeks before FreeBSD 13.0 was due to be released,
FreeBSD core developer Kyle Evans emailed the list about integrating
wireguard-tools (wg(8) and such). In the ensuing discussion I mentioned
that we really need to get the actual if_wg kernel implementation up to
snuff. We took the conversation to IRC, and agreed that we should work
on figuring out what to do before the release date...
And with regard to this issue, this is exactly what we should see; the core developers reacting to an obvious failure of process.FWIW I guess we'll have this covered in it's own Office Hours. From yesterday's <freebsd-hackers>:Code:
[...] This incident highlights the need to do this work more proactively, and to maintain a robust, multi-layered development process that can catch problems as they fall through the cracks. [...]
Yeah, and then immediately disqualify anyone the "highly skilled" psychologists approve.I'm not sure if I should seriously suggest to add an interview done by a team of professional, highly skilled psychologists to check the so-called soft skills, before granting a commit bit to a developer.
Sigh, you miss the point. It's in RC, not some branch somewhere being developed, it's in RC.
My point is that psychologists are not in a position to make a decision who should be on a team or not. It's up to other team members, e.g. Core and Committers. Of course based on whatever criteria they're comfortable with. It's up to them. Team decides whether Terry Davis belongs to the team or not. Especially in volunteer based open source projects. At least scientists and engineers gave us Maxwell's equation, and UNIX kernel. What are psychology achievements? -- beside calling people lunatics, and lock them up in booby houses.I welcome your critical mind, but I can't relate any of this to the issue. Please elaborate.
Reaction score: 9
team of professional, highly skilled psychologists to check the so-called soft skills, before granting a commit bit to a developer.
Let's strike a happy medium. I volunteer.Yeah, and then immediately disqualify anyone the "highly skilled" psychologists approve.
Actually, it seems to be also about code quality.
IMHO that is your personal feeling. Where can I read that in the Ars Technica article? You keep denying that this incident revealed a serious underlying problem.FreeBSD has been doing quality, commendable work for over 25 years but some are wanting to pretend this one ugly bug in that process disqualify everything accomplished so far. To use this as a reason to disrespect all this work
Yes, and that should not be denied, otherwise, there might be a next time, and there might be less luck involved.You keep denying that this incident revealed a serious underlying problem.
I don't think so. You don't have to enforce every rule technically. It should of course ring alarm bells when something like this happens. So, it didn't (immediately) in this case, but that doesn't necessarily mean the problem is structural. It could be a hint, but the team has to analyze that…Of course it is a structural problem if a committer can close any review as "not accepted" on his own.
Oh, the irony!I have to say that I see some quite unhelpful ad hominem attacks on the messenger here.
I reject your false choice. The first Ars article on the subject was good and informative. The second one is a pure exercise in muckraking and concern trolling. Salter delivers a clinic on the latter here:Now, you can do two things...
And the muckraking takes the form of splashing the seamy details of Macy's criminal past all over the Internet. And I'm supposed to worry about ad hominem attacks against Salter? Please.FreeBSD is an important project that deserves to be taken seriously. Its downstream consumers include industry giants such as Cisco, Juniper, NetApp, Netflix, Sony, Sophos, and more. The difference in licensing between FreeBSD and Linux gives FreeBSD a reach into many projects and spaces where the Linux kernel would be a difficult or impossible fit.
Reaction score: 86