Message-ID: <b14e81f00707280618m73461fdfx989d87a3a0074192@mail.gmail.com>
Date:	Sat, 28 Jul 2007 09:18:14 -0400
From:	"Michael Chang" <thenewme91@...il.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Kasper Sandberg" <lkml@...anurb.dk>,
	"CK Mailinglist" <ck@....kolivas.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [ck] Re: Linus 2.6.23-rc1

On 7/27/07, Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> Con ended up arguing against people who reported problems, rather than
> trying to work with them.

I do recall there is one issue on which Con wouldn't budge -- anything
that involved boosting certain kinds of processes in the kernel. He
said that it would defeat the whole point of the way he had designed
it, and that nicing could work just as well. Perhaps there could have
been a better way of handling that issue, such as adding (yet another)
kernel compilation configuration option for this code (since Con
didn't believe it would help all users).

> Andrew also reported an oops in the scheduler when SD was merged into -mm,
> so there were other issues.

I don't know how you can blame Con for not finding a PPC oops before
SD was merged into -mm, considering he seemed to be coding solely on
an x86-based architecture. Of course, you could say that his design
should have factored in all the architectures and such, but even the
best design can fall apart if it doesn't get tested somewhere. Again,
this is probably a subjective case in that Con might have pushed SD to
-mm rather early; but considering the readership of his -ck list, I
don't think it would have been tested on anything other than X86 until
it went into -mm because I've ever seen anyone on -ck report "it works
on <something other than x86/x86-64/IA64>". I don't know what made it
on to other lists, but Con tried his best to fix this oops, and unless
it was done privately, this oops was never re-reported. (Now, if SD
was _STILL_ causing this oops on PPC, I can see how this might be a
concern.)

> > As far as im concerned, i may be forced to unofficially maintain SD for
> > my own systems(allthough lots in the gaming community is bound to be
> > interrested, as it does make games lots better)
>
> You know what? You can do whatever you want to. That's kind of the point
> of open source. Keep people honest by having alternatives.
>
> But the the thing is, if you want to do a good job of doing that, here's a
> big hint: instead of keeping to your isolated world, instead of just
> talking about your own machine and ignoring other peoples machines and
> issues and instead of just denying that problems may exist, and instead of
> attacking people who report problems, how about working with them?
>
> That was where the SD patches fell down. They didn't have a maintainer
> that I could trust to actually care about any other issues than his own.

So if we found a better maintainer who would commit to maintaining the
SD patches, would you still be willing to consider merging them? Is
this what you're saying?

> I'm happy that SD was perfect for you. It wasn't for others, and it had
> nobody who was even interested in trying to solve those issues.

-- 
Michael Chang

Please avoid sending me Word or PowerPoint attachments. Send me ODT,
RTF, or HTML instead.
See http://www.gnu.org/philosophy/no-word-attachments.html
Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists