Intentionally buggy commits for fame—and papers
Intentionally buggy commits for fame—and papers
Posted Apr 23, 2021 8:25 UTC (Fri) by andy_shev (subscriber, #75870)Parent article: Intentionally buggy commits for fame—and papers
Posted Apr 23, 2021 11:31 UTC (Fri)
by gmgod (guest, #143864)
[Link] (2 responses)
Though I can't possibly condone the way things were done in this instance, identifying and quantifying how buggy commits are passing through review seems important when said review fails so evidently. I want kernel developers to have tools and workflow that efficiently/easily identify bugs (whether intentional or not) and spend less time on something so boring. This is not the case.
Kernel devs should try to work *with* researchers instead of banning them (again, I'm aware those specific researchers screwed up big time in this case). All the papers I can read on the subject are really frightening in terms of bug introduced and time-to-fix.
Posted Apr 23, 2021 11:44 UTC (Fri)
by wtarreau (subscriber, #51152)
[Link]
There are tons of tools, but the very concept of "review" exists because at some point you need a human. And it turns out that a lot of tools and imposed processes can drain a lot of human time as well. In the end it's important to find a sweet balance of tools and processes that makes everyone work at their best efficiency.
Avoiding errors is pointless because they will always exist, and there are diminishing returns on the efforts you add. Instead what matters is that they're quickly spotted and fixed. Here the tools and automated tests in place are helping a lot.
Still more participants would be nice. If you don't review, why wouldn't you start ? Just spot a patch that you can read, from time to time, return some suggestions or respond with a "reviewed-by" so that nobody else spends time on it and you'll help by saving someone's valuable time. You don't necessarily need to be skilled on the subject if you can read code and be curious. It doesn't matter if you make a mistake once in a while (though not too often): if your work eliminates 90% of the someone else's work and requires to be fixed 10% of the time, it's already 81% saved!
Posted Apr 26, 2021 0:45 UTC (Mon)
by rgmoore (✭ supporter ✭, #75)
[Link]
Kernel developers have spent a lot of time working with researchers; there are a bunch of things in the kernel that were put there as a result of academic research. That includes security testing, e.g. the Coverity scanner. But working together is a two-way street. I haven't seen anything in the discussion of this issue that shows these researchers made any attempt to work with the kernel developers, and that really has to happen first. It seems extremely unlikely to happen in this case, considering how seriously the relationship has already been damaged.
Intentionally buggy commits for fame—and papers
Intentionally buggy commits for fame—and papers
Intentionally buggy commits for fame—and papers
Kernel devs should try to work *with* researchers instead of banning them (again, I'm aware those specific researchers screwed up big time in this case).