Linus: What's Wrong With The Whole DRM Crowd?

[ArchLinux]

There is no cost in BFS. And CK didn't intent to push to mainline simply because mainline does not accept two schedulers; this was made clear years ago.

Yeah, it was made clear years ago that there _is_ a cost in BFS, which only appears in systems with a _lot_ of CPUs, though. The options to prevent this were to either use two schedulers _or_ modify the code in a way CK wouldn't like.

[PsynoKhi0]

It's not the first time they have pulled shenanigans like this, frustration gets the better of everyone eventually.

Especially when this kind of issues seem to repeat themselves. There should be examples of previous outbursts similar to this one on this very site.

Anyway both parties have their reasons, I guess.

[Veerappan]

I am a bit lost with all the git jargon that is used in this example email, and others. I wonder what is the easiest to understand tutorial out there for git that would allow me to understand why "rebasing" can be a good or bad practise.

Examples of how to use rebase, but not much explanation about why rebasing publicly committed code is bad:

http://help.github.com/rebase/

[Delgarde]

I am a bit lost with all the git jargon that is used in this example email, and others. I wonder what is the easiest to understand tutorial out there for git that would allow me to understand why "rebasing" can be a good or bad practise.

The simplest explanation is that rebasing a tree changes the history of that tree. Which is bad when that history has already been made public, and other trees have been pulling changes from that history. It's not disastrous in the sense of data corruption, but it does make it a lot harder to track the history of a change.

[RealNC]

As for BFS scheduler, it gives you the speed but with a noticable cost. Kolivas never even intended to push it to mainline.

There is no cost in BFS. And CK didn't intent to push to mainline simply because mainline does not accept two schedulers; this was made clear years ago.

[deanjo]

I also agree that he has good points to be strict on the kernel development conventions.
Still, I don't see why it is necessary to be impolite to make a point.

It's not the first time they have pulled shenanigans like this, frustration gets the better of everyone eventually.

[ArchLinux]

I also agree that he has good points to be strict on the kernel development conventions. Still, I don't see why it is necessary to be impolite to make a point.

In my opinion this is just embarrassing, even if he just might be over-worked as the final authority in the kernel development process...

Oh please. Nobody ever said coding linux is a bed of roses. 1) You really need to have some skills, being a programmer expert is only enough for the minor changes. 2) If you do bad things, e.g. rebase something for no reason, commit poor code you, without question, _will_ be told that. The way you are told that depends on who, and in what mood, happens to response to such 'action' and how big your error was.

You have to understand that it's a total different world in the kernel world.

[siride]

I also agree that he has good points to be strict on the kernel development conventions.
Still, I don't see why it is necessary to be impolite to make a point.

In my opinion this is just embarrassing, even if he just might be over-worked
as the final authority in the kernel development process...

Because that's how Linus is. More importantly, everybody knows it. So getting flamed by Linus probably isn't that big of a deal. Dave's email back to Linus hardly showed that he felt affronted by Linus's commentary.

[entropy]

I also agree that he has good points to be strict on the kernel development conventions.
Still, I don't see why it is necessary to be impolite to make a point.

In my opinion this is just embarrassing, even if he just might be over-worked
as the final authority in the kernel development process...

[siride]

I am a bit lost with all the git jargon that is used in this example email, and others. I wonder what is the easiest to understand tutorial out there for git that would allow me to understand why "rebasing" can be a good or bad practise.

http://git-scm.com/

Just search around in the documents or the wiki. There are tutorials as well as full-blown, in depth explanations of how things work. TBH, the man page for git rebase will probably suffice to explain why you don't rebase public branches. It even has ascii-art diagrams.