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.
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.
[...] 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.
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?
Blaming s/o who's code is cluttered with
#ifdef's and constraints unconditionally return true has 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.
And with regard to this issue, this is exactly what we should see; the core developers reacting to an obvious failure of process.
Yeah, and then immediately disqualify anyone the "highly skilled" psychologists approve.
Sigh, you miss the point. It's in RC, not some branch somewhere being developed, it's in RC.
Yeah, me too. I understand why Donenfeld had to make a big deal out of this, but I can see how Evans got stuck in the middle of a bad situation. That is a bummer.
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.
Let's strike a happy medium. I volunteer.
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.
Yes, and that should not be denied, otherwise, there might be a next time, and there might be less luck involved.
Of course it is a structural problem if a committer can close any review as "not accepted" on his own.
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…
Oh, the irony!
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:
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.
So my calling it an ugly bug in the process that needs fixing is denial? I've said, perhaps three times in this thread that it's a problem with the process.
I can confirm this, having read some threads there.
Really, forbidden?