[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0805080112030.3318@apollo.tec.linutronix.de>
Date: Thu, 8 May 2008 01:46:18 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Pavel Machek <pavel@...e.cz>
cc: Yinghai Lu <yhlu.kernel@...il.com>, Adrian Bunk <bunk@...nel.org>,
Rene Herman <rene.herman@...access.nl>,
Ingo Molnar <mingo@...e.hu>,
Linux Kernel <linux-kernel@...r.kernel.org>, hpa@...or.com,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org
Subject: Re: 2.6.26, PAT and AMD family 6
On Thu, 8 May 2008, Pavel Machek wrote:
> On Thu 2008-05-08 01:02:52, Thomas Gleixner wrote:
> > On Thu, 8 May 2008, Pavel Machek wrote:
> > > And then, factor out code marked # into separate function, and call it
> > > from all three places.
> >
> > And while you are at it, why don't you send a patch which makes this
> > all go away instead of wasting time producing pseudo code?
>
> Because I expect Ingo & Yinghai to do the work, and then test it, and
> then add changelog, and then commit it. I expect Yinghai to learn how
> to use functions in the process.
Oh yes. He is the perfect kernel newbie who needs to be tought how to
use functions.
No, he is not. He provided a lot of valuable patches and he always was
cooperative when his patches were reviewed.
You are completely missing the point. We, the x86 maintainers accepted
and committed that functional correct but stylistically imperfect
patch. It's mainline now. We can spend tons of time to discuss how it
could have done better, but isn't it one of the virtues of Open Source
that we can actually prove that it can be done better ? From such a
patch others can learn at least as much as from ivory tower post
factum analysis.
We can all sit down and resort to "I expect that XYZ do the work". Is
this making things any better?
Thanks,
tglx
P.S: we all wasted at least 10 times of the time to write that patch. :(
--
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