Re: [ck] Re: Linus 2.6.23-rc1

Martin Steigerwald
2007-07-29T09:37:26Z

[-- Attachment #1: Type: text/plain, Size: 5240 bytes --]

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@linux-foundation.org> 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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]