And, again, none of that happened.If he hadn't made it public, and FreeBSD 13 was out today
And, again, none of that happened.If he hadn't made it public, and FreeBSD 13 was out today
No. Writing tests/constraints that unconditionallyreturn true
are not among the skills that I would consider the most wanted for a kernel
You are agreeing that I am right and that is true--nothing happened. Thank you. How it got to that point is an issue that needs addressing as I have stated more than once. Going on and on about something that did not happen is pointless and time consuming for us and this thread that is only a concern for forums and Ars but nowhere else that matters.
This is a horrible question to ask and I've seen it asked on the amateur forums and Ars, too. Every project everywhere has something that was missed and had close calls where one can ask that same question. Again, it's pointless to ask and only worrisome to those who only want to make themselves feel superior.
Which has nothing to do with what I said. The system works. It works well. In this case, a hole was found--a bug in the system. The bug will be fixed but the software was never released. In the meantime, nothing happened.But by luck rather than good management. If you think luck is a way to control a software project, then, well good luck running it, you'll need it.
Ah thanks for that.From the Wiki: Phabricator is a FreeBSD-hosted service that provides pre-commit code review workflows.
A website where a developer proposes a change or addition to FreeBSD with code changes on display.
There are commiters who are summoned by 'Herald' the phab bot for code review and some commiters will set themselves as a reviewer.
So the code review should provide fixes for code style and function.
The code author has to fix code to pass go at each stoppage..
Then when enough reviewers approve it the code gets commited to HEAD.
So phab is a code fixup and review process.
Our code collabration tool.
According to the article, "the landlord from hell" closed reviews without addressing the problems and completely ignoring them.I can assume that the code that goes to HEAD is reviewed, and therefore the problem in this case is a failed review?
Slightly tangential note, but my questions to mmacy@ about original
wireguard commit (and ZoL, FWIW) or Phabricator comments had not been
answered; I also recall reviews being closed in "not accepted" state
by him. While I appreciate the heavy-lifting, developers should be
ready to explain and sometimes defend their work on public forums.
Uhmmmm.... okay, so if i get it correct:According to the article, "the landlord from hell" closed reviews without addressing the problems and completely ignoring them.
True that, but if the reviewers are aware that the review has been closed they can still do something.The fact that a committer can close any review as "not accepted" is the main problem here. I mean, code reviews are there for a reason.
Don't worry, FMLU much of thatEDIT: Sorry, something else: 40000 lines of code is a hell of a review.
#ifdef LINUX
... dead code ...
#endif /* LINUX */
Just scroll through the code and see yourself what an insane amount of redundant garbage code could have been thrown out in case the system crypto could have been used...danfe said:On a larger scale, is adding another pile of crypto bits necessary? Would it be feasible to use existing crypto framework instead? I've heard Linux folks eventually forced the author to rewrite this zinc thing of his as a simple wrapper over kernel crypto API. What's the situation in our case?
I am not aware of exact times when he had commit bit and when not.IIRC, the most common cause is "commit bit taken in for safekeeping" - in other words, the committer has been absent from FreeBSD project work for a long time, or that the committer self asks for the commit bit to be taken in, because of ENOTIME to work on FreeBSD.
Matt Macy said:I've been asked to ...
In the FreeBSD code?Don't worry, FMLU much of that isC:#ifdef LINUX ... dead code ... #endif /* LINUX */
This boils it down, what actually happened. Like a bus full of soccer fans and the bus driver prevented an accident in the last minute by kicking in the balls of the fanatics who had their grip already on the steering wheel.. . ., as there were a lot of fans of those who wanted to see WireGuard in FreeBSD and PF Sense. There was a lot of encouragement to get it in by fans for some time, and putting it in at the last minute will always be prone to problems. . . .
No luck involved. Another Freebsd committer reached out to Donenfeld (lead author of Wireguard) with concerns about the implementation.You're kidding right? Sure, you're right, nothing happened but it wasn't through review or testing, but rather luck that the author of wireguard looked at the code and made it public.
So there's no possibility for rehabilitation, ever? Why don't we just throw everyone in prison forever for every crime?A criminal (served 4 years and 4 month)
A coward (fled to Italy to avoid prosecution)
A misanthropist (attempting to illegally evict tenants from a building he had bought)
A psychopath (forged extremely threatening emails appearing to be from the tenants themselves)
I'd revoke his commit bit.
Now we get nearer to the issue.Please compare the following two occurrences:
- When I filed in a (truly minor) bug report recently (PR 253861), I was kindly asked to write a test to asure it could not happen again (because the genuine author is too busy commiting more flaws like that?). So, to proceed with an already existing minor bug, the reporter is requested to provide tests... versus:
- FMLU that guy from the WireGuard project (Jason A. Donenfeld) wrote a bunch of tests for the FreeBSD in-kernel implementation, when several dozens kLoC have already been commited... So, to commit dozens of kLoC that conforms to numerous commonly accepted worst-practices of C programming, all you need is mentorship from Sean Bruno. Just let the others write the tests.
A criminal (served 4 years and 4 month)
A coward (fled to Italy to avoid prosecution)
A misanthropist (attempting to illegally evict tenants from a building he had bought)
A psychopath (forged extremely threatening emails appearing to be from the tenants themselves)
I'd revoke his commit bit.
One of my most bitter professional memories is of when I discovered that I had introduced a regression into a release candidate. I further realized that this regression was only going to affect our largest and most important customers.One main difference between free software and commercial software used to be that free software is more agile (that was true long before "agile" became a buzzword): it once took me 23 hours to get a fix into the HEAD of sendmail, it took more than a year to get a fix into a big commercial unix.
Don't get me started on the "agile" nonsense. There's so much ridiculousness there. I'm only going to quote a former colleague that liked to say "you don't run a marathon by breaking it up into a series of sprints".The reason for that, as I think, was that in the free software those people were in charge who were concerned with the software - often those who had written it in the first place, while in business people in charge were concerned mainly with the business. (And this is a difference that you cannot overcome with "agile" methodology - which is why "agile" is mostly BS.)
At the risk of a circular argument: It has everything to do with what you stated. There is no system unless your system is luck.Which has nothing to do with what I said. The system works. It works well. In this case, a hole was found--a bug in the system. The bug will be fixed but the
software was never released. In the meantime, nothing happened.
You are now stating FreeBSD's code, due to this one issue, is managed by luck which is a preposterous statement.
Closing the barn door after the chickens got out.Some sort of fair and balance signalling, I assume?!
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.At the risk of a circular argument: It has everything to do with what you stated. There is no system unless your system is luck.
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.Let's all enjoy a good, juicy two minutes hate on Macy.