University of Minnesota intentionally worked to introduce vulnerabilities into the mainline Linux kernel.

[rene]

The offenders should have a lifetime ban from contributing anything to the kernel [ ... ]

Most decidedly not as that would mean that it is not all about the code after all. That same group has over the years submitted tens to hundreds of valid patches that improved quality of the kernel: any future patch they send that does the same is and needs be as welcome as when it came from anyone else.

Theoretically. There's still the practical issue of course that it may be decided to be too much work to painstakingly have to review patches that come from people you distrust so that you'd rather just drop them all on the floor outright --- but then it's a process-matter. It may never be a punitive one lest one spits on the very fabric of open-source development or that of Linux specifically. It's all about the code.

[Portreve]

The offenders should have a lifetime ban from contributing anything to the kernel [ ... ]

Most decidedly not as that would mean that it is not all about the code after all.

I've re-read your post several times, and I can't for the life of me understand what in the world you're talking about.

"It's all about the code"? Heck yeah it's all about the code: code which can be trusted, not code which for whatever reason seeks to cause problems.

It may never be a punitive one lest one spits on the very fabric of open-source development or that of Linux specifically. It's all about the code.

The spitting has already been done. Now it's time to clean things up and take steps to keep this from happening again.

[rene]

I've re-read your post several times, and I can't for the life of me understand what in the world you're talking about.

It's very fundamental to Linux development though. All code submitted to the kernel goes through maintainers that either review the code themselves or trust reviews by other expert on the subject before integrating it or not. The point here is that as soon as code has passed/not passed that review process it is considered good/not good enough --- whether written by Linus Torvalds, Genghis Khan or professor Lu; if the code is good it goes in, if it is not it does not.

Now we of course all understand humanity well enough to know that not any process is in fact all that free of subjectivity (nor would I say it necessarily should be) and certainly it's the case that people who've proven themselves trustworthy deal with less scrutiny than a random one-off submitter does, and most certainly that vice versa people who have proven themselves untrustworthy deal with a heck of a lot more (at best), but it's still very much the principle of things.

And any maintainer may as such certainly elect to limit or deny review (hence chance or possibility of code being accepted) on grounds of e.g. a certain person or group costing more in valuable review bandwidth than what even their good contributions warrant, but only in that sense and not in a punitive one. Latter would after all mean rejecting code only on grounds of not liking its origin, its submitter, rather than said code itself. And that flies in the face of this development model being about "technical excellence" or at least, about code and not about humans.

Whether code can or can not be trusted is determined by the review of said code; not by election, consensus or history. Ideally.

[DAMIEN1307]

Most decidedly not as that would mean that it is not all about the code after all.

"It's all about the code"? Heck yeah it's all about the code: code which can be trusted, not code which for whatever reason seeks to cause problems

If this were the business for profit world, heres what would be happening...

Employee steals, he's fired...If employee habitually lies or deceives employer and other employees, he's fired...If an employee falsifies his paper work or computer work, He's fired...Why ???...He can't be trusted...Not only fired, but not eligible for rehire because he cannot be trusted not to do it ever again.

It's not just "all about the code" but also can the code ever be trusted again because of who is supplying it ?

I agree with Portreve on this one...DAMIEN

[rene]

The kernel's development process and specifically then the review process is in essence quite simple;

Code: Select all

if (review(submission) == PASSED) {
	accept(submission);
} else {
	reject(submission);
}

Note how "submitter" is not a parameter to either accept() or reject()...

[Portreve]

In order to submit code for consideration, one must have an account on a system used for said activity. So, even though this is strictly a matter of semantics, not everybody can submit code for inclusion; only people (whether as individuals or as representatives of some kind of organization, like Harvard or IBM) with accounts can.

Therefore, in the first instance, it is not about the code; it is about the people submitting it. This is exactly as it should be.

The only sense in which it's "all about the code" is that aspect of the development process which is a meritocracy. In that sense, code is considered for inclusion not based on, for example, the color of your skin, but whether the code is any good. This, too, is how it should be.

However, people don't (or at least shouldn't, though I suspect it's more a matter of don't) last very long or keep their accounts if in truth they're just ne'er-do-wells, like these idiots are.

[rene]

In order to submit code for consideration, one must have an account on a system used for said activity.

No. Emailing it to a maintainer and/or the linux-kernel mailinglist is enough and historically how all Linux development was done. These days git is a big part but is not in that sense conceptually different: you now just mail the maintainer and/or the linux-kernel mailinglist to pull your repository (if you're savvy enough; for small time developers submissions by email is still very much the norm).

And in that sense also see the actual submission this is all about, also linked above somewhere: https://lore.kernel.org/linux-nfs/20210 ... 1@umn.edu/. As you can see, simple email to a number of the in the field involved maintainers, with CC to the linux-kernel and in this case linux-nfs mailinglists.

There is no a priori vetting. Things really work very fundamentally as I described.

[Portreve]

Why are we continuing this discussion? Nothing is changed. We're not advancing the argument.

[rene]

Incorrigible. The supplied information on the Linux development process --- a process which you evidently did not have the faintest clue about before you started talking of it --- means that, as is very fundamental to the issue of "banning" someone as you suggested as both valid and desirable, that is not how things work. There is in this process no a priori vetting of people; only vetting of code.

Again, with all the caveats I mentioned earlier and which I will not repeat even if only since you are clearly more interested in appearing right than in being right. As sort of a nice analogon of the issue itself in fact: Linux development is (again, ideally) all about latter and could not give a shit about former.

[Pierre]

Why are we continuing this discussion? Nothing is changed. We're not advancing the argument.

and so another Topic is Locked.

the original point, was made way back, on the other page . .