Re: [ck] Re: Linus 2.6.23-rc1

[Martin Steigerwald]

Am Samstag 28 Juli 2007 schrieb Linus Torvalds:
> On Sat, 28 Jul 2007, Diego Calleja wrote:
> > El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds 
<torvalds@xxxxxxxxxxxxxxxxxxxx> escribió:
> > > So "modal" things are good for fixing behaviour in the short run.
> > > But they are a total disaster in the long run, and even in the
> > > short run they tend to have problems (simply because there will be
> > > cases that straddle the line, and show some of _both_ issues, and
> > > now *neither* mode is the right one)
> >
> > I fully agree with this, but plugsched could have avoided this
> > useless "division" on the topic of SD vs CFS. IMO that counts as an
> > advantage, too ;)
>
> Sure. I actually think it's a huge advantage (see the ManagementStyle
> file on pissing people off), but at the same time, I don't like playing
> politics with technology. The kernel is a technical project, and I make
> technical decisions.

IMHO thats an illusion. The kernel has become a community project pretty 
soon after you have released it initially. And the community members are 
human beings. Thus while the kernel source code in itself for sure 
describes technical processes, the kernel is more than just a technical 
project.

> So I absolutely detest adding code for "political" reasons.

I can understand this and I agree to it, cause it would mean fixing 
political things on technical grounds and thus not fixing them at all.

> I personally feel that modal behaviour is bad, so it would introduce
> what is in my opinion bad code, and likely result in problems not being
> found and fixed as well (because people would pick the thing that
> "works for them", and ignore the problems in the other module). So
> while I don't like making irreversible decisions (and the choice of CFS
> wasn't irreversible in itself, but if it pisses off Con, _that_ is
> generally not reversible), I dislike even more making a half-assed
> decision.

I agree to this to some extent. But if the mainline kernel does not 
contain suitable solutions for one subsystem people will tend to plug in 
other solutions that work for them even where there is no boot or runtime 
plugability.

I have been using TuxOnIce (formerly suspend2) for quite some time and 
didn't even try the in-kernel-suspend-to-disk stuff since quite some 
kernel versions since I could not have been bothered anymore after it was 
failing back then.

So when there are two different approaches with good following it may have 
be good to have some plugability for testing things. But it may be 
difficult to remove it afterwards again..., but it would still be 
possible to remove plugins that are only used rarely and they how the 
other ones evolve.

> So rather than making a choice at all, my other choice would have been
> to not merge _either_ scheduler, and let people just continue to fight
> it out. Would that have made people happier? I seriously doubt it.

I tried speaking to Con and Ingo whether they could settle their issue 
with one another and work together. In *private* mails, away from all the 
flame throwing.

Actually I believe that human things should be resolved on the human side, 
not on the technical one. And as I perceive no serious attempt has been 
made on that - except my own maybe.

Maybe just writing an email to both Con and Ingo where you told both of 
them your concerns and thoughts would have helped a lot. A

"Hi Con and Ingo, 

Con, I do not believe that you are able to maintain SD for reason 1,2 and 
3. But I do think that Ingo could. But I think, that you wrote great code 
and brought in good scheduler concepts and ideas to the Linux world. Now 
Ingo has CFS and you have SD... could there be a way for you to stay 
involved with scheduler issues and work together with Ingo? If so how 
could it look like?

Ingo, do you see areas where Con can help you with? Are there things in SD 
that you would like to have in CFS? Do you see a way to work with Con 
together on the scheduler?"

(just a draft;-)

for example. It would have given Con some recognition for his work. It 
could have helped to address the political, well not even the political, 
but the human issue here. I believe that this is what Con missed the 
most: Getting some form of recognition from the "official" kernel people! 
I tried to give some recognition, but I am "just" a user of his patches.

Would that have been difficult for you to write, Linus?

Its not too late for giving Con some recognition. A simple 

"Hi Con, 

I am sorry that you decided to leave kernel development. I felt I had to 
make a decision about the scheduler thing and these where my concerns...

I just wanted to tell you that I did not mean any personal offence with 
you and did not have any real issue with your code at all, 

Regards Linus" 

as an aftermath could still help. Just a little gesture maybe - but it can 
make a big difference. Maybe without even asking him to come back... I 
think Con made his decision for now at least.

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Attachment: signature.asc
Description: This is a digitally signed message part.