From: Ingo Molnar <mingo@elte.hu>
To: Christoph Lameter <clameter@sgi.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>, Andi Kleen <ak@suse.de>,
Jeremy Fitzhardinge <jeremy@goop.org>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [patch 0/3] Per cpu relocation to ZERO and x86_32 percpu ops on x86_64
Date: Fri, 30 Nov 2007 20:45:17 +0100 [thread overview]
Message-ID: <20071130194517.GD9928@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.64.0711301043380.1919@schroedinger.engr.sgi.com>
* Christoph Lameter <clameter@sgi.com> wrote:
> On Fri, 30 Nov 2007, Ingo Molnar wrote:
>
> > if you treat testing and review efforts like that they might have to
> > wait even longer :-( "My stuff is there somewhere amongst 1415 -mm
> > patches. Thank you for your interest and buzz off already."
>
> Well I guess you have to get used to maintainership I think. F.e. the
> s390 people tested this patchset without requiring a backport.
> Typically arch maintainers test mm and do not force the patches back
> into mainline.
Huh?? This is getting absurd. Look at it from my perspective: i spent a
few spare cycles on a Friday afternoon to check a few x86 relevant
patches that looked interesting to me personally. At the moment they are
still cooking in -mm and were not submitted to upstream merging yet - so
i did not expect anything from them, but i wanted to help out because
the patches looked good.
This was not any "formal" x86 maintainance activity - your patches are
still cooking. But i was thinking about maybe putting these patches into
the x86 test grind to get them shaken out some more the random 1000
bootup tests a day that it does. When integrating your patches I found a
bug and tentatively reported it to you, pointing out that it could
easily be my merge fault. Basically i was offering you to let your
patches cook in another kitchen as well. I never before had a negative
response to that :-/
So i expected some "great that you are looking at this stuff, lemme help
you sort it out, you missed these 2-3 patches in -mm" reaction (that's
how i'd have reacted to you doing the same) instead i got these very
surprising and fundamentlly hostile responses from you, an unfriendly
"test -mm and dont pick out individual patches" suggestion and now this
mail from you with this rather subtly formulated condescending tone:
> Well I guess you have to get used to maintainership I think. [...]
so i guess i'll leave it here for now with your percpu patches, i've got
far better things to do on a Friday afternoon :-/ We'll deal with your
stuff once it gets so far as upstream integration.
> I am a bit surprised since Andi and I never had this issue.
huh??? I am really wondering where this hostile attitude of yours comes
from. Getting patches build and boot is something architecture
maintainers do on a regular basis, it's a minimum requirement before
getting something merged into an architecture.
And btw., -rc3-mm2 seems to have grown a spontaneous reboot problem,
that looks quite similar to what i saw:
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm2/announce.txt
| - First bug report: after ten minutes happily compiling kernels my
| 2.6.24-rc3-mm2 x86_64 box spontaneously rebooted.
so from now on i guess i'll have to tag you as "does not want any
advance testing and review help with his patches" person and will leave
you alone.
Ingo
next prev parent reply other threads:[~2007-11-30 19:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-30 6:43 [patch 0/3] Per cpu relocation to ZERO and x86_32 percpu ops on x86_64 Christoph Lameter
2007-11-30 6:43 ` [patch 1/3] Percpu infrastructure to rebase the per cpu area to 0UL Christoph Lameter
2007-12-02 3:04 ` Rusty Russell
2007-12-02 3:13 ` Rusty Russell
2007-11-30 6:43 ` [patch 2/3] X86_64: Declare pda as per cpu data thereby moving it into the cpu area Christoph Lameter
2007-11-30 6:43 ` [patch 3/3] x86_64: Make the x86_32 percpu operations usable on x86_64 Christoph Lameter
2007-11-30 20:07 ` Christoph Lameter
2007-11-30 11:24 ` [patch 0/3] Per cpu relocation to ZERO and x86_32 percpu ops " Ingo Molnar
2007-11-30 11:26 ` Ingo Molnar
2007-11-30 17:08 ` Christoph Lameter
2007-11-30 17:19 ` Christoph Lameter
2007-11-30 18:00 ` Ingo Molnar
2007-11-30 18:24 ` Christoph Lameter
2007-11-30 18:35 ` Ingo Molnar
2007-11-30 18:47 ` Christoph Lameter
2007-11-30 19:45 ` Ingo Molnar [this message]
2007-11-30 19:59 ` Christoph Lameter
2007-11-30 20:06 ` Ingo Molnar
2007-11-30 20:09 ` Christoph Lameter
2007-11-30 20:26 ` Ingo Molnar
2007-11-30 20:43 ` Ingo Molnar
2007-11-30 18:41 ` Ingo Molnar
2007-11-30 18:43 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071130194517.GD9928@elte.hu \
--to=mingo@elte.hu \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).