From: Ingo Molnar <mingo@elte•hu>
To: Stephen Rothwell <sfr@canb•auug.org.au>
Cc: eranian@gmail•com, linux-next@vger•kernel.org,
Alexander van Heukelum <heukelum@mailshack•com>,
the arch/x86 maintainers <x86@kernel•org>,
"H. Peter Anvin" <hpa@zytor•com>,
Thomas Gleixner <tglx@linutronix•de>,
Peter Zijlstra <a.p.zijlstra@chello•nl>,
Andrew Morton <akpm@linux-foundation•org>
Subject: Re: linux-next: manual merge of the perfmon3 tree
Date: Wed, 26 Nov 2008 04:33:18 +0100 [thread overview]
Message-ID: <20081126033318.GE8242@elte.hu> (raw)
In-Reply-To: <20081126140032.72d86f17.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb•auug.org.au> wrote:
> > In any case, until that happens and until there's agreement with
> > the x86 maintainers (there's none at the moment) the perfmon3 tree
> > (or at least its x86 bits) needs to be removed from linux-next. I
> > already see a number of problems with the patchset that we'll have
> > to work out via an iterative review process.
>
> That process has been happening except it seems that the x86
> maintainers haven't bothered to participate. [...]
uhm, that's plain not true. There are three x86 maintainers and we
take pride in replying to all x86 patch submission within a day
typically, so i reject your suggestion.
We know and knew about the existence of the perfmon patches, but they
were always in the vague RFC category and never directly submitted or
Cc:-ed to us.
The authors of those patches never even bothered to Cc: the x86 arch
maintainers, and never asked for those patches to be Ack-ed, accepted
or reviewed. If that is not so, please show me the lkml link that
contradicts my claim.
And how did we notice that this was going on? Not because we were
told, but due to a bad perfmon commit modifying x86 code that suddenly
showed up in linux-next ...
> [...] If, as you say, all the x86 parts have to go via the x86 tree,
> then be aware that this woukd probably delay x86 perfmon integration
> until 2.6.30 or later [...]
Why should that be so?
All i'm asking for you is to follow the upstream kernel integration
process. All i'm asking you is when a new tree matches such a wide
pattern of x86 modifications:
25 files changed, 2340 insertions(+), 6 deletions(-)
_to at least Cc: the maintainers and ask their opinion_
this isnt just a file here and there. It goes straight into the guts
of the architecture.
All i'm asking for is to not use linux-next as a backdoor to get
_unreviewed_ and _clearly bad_ patches behind the back of architecture
maintainers who specifically asked to be involved.
> [...] (*cough* ftrace *cough*). [...]
I'm not sure what you want to imply by that. ftrace was delayed for
several kernel releases before it went upstream and the initial port
went upstream with the full knowledge (and participation) of the
architecture maintainers. (x86, incidentally)
> [...] As Andrew pointed out in another thread you seem to have
> missed, the integration of perfmon (or something like it) is way
> over due. The way he suggested to go forward was to get it into
> linux-next and aim for 2.6.29 integration.
>
> Several other architectures want this code in the kernel, so if they
> have to wait for the x86 maintainers to decide what they want, then
> the only way forward may be to separate the generic parts of the
> code and get that integrated along with one of the other
> architectures.
There's a proper process for merging brand new features, and it starts
with asking the opinion of the maintainers. This isnt just a random
stale subsystem no-one is interested in. This is a highly active piece
of code maintained by three maintainers. This subsystem saw more than
5800 commits in the last year alone.
Stephen, this is kernel maintenance 101, and you must follow it.
Ingo
next prev parent reply other threads:[~2008-11-26 3:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-25 10:03 linux-next: manual merge of the perfmon3 tree Stephen Rothwell
2008-11-25 10:22 ` Ingo Molnar
2008-11-25 14:40 ` stephane eranian
2008-11-25 15:33 ` Ingo Molnar
2008-11-25 16:36 ` stephane eranian
2008-11-25 16:51 ` Ingo Molnar
2008-11-26 3:00 ` Stephen Rothwell
2008-11-26 3:33 ` Ingo Molnar [this message]
2008-11-26 7:06 ` Paul Mackerras
2008-11-26 7:16 ` Ingo Molnar
2008-11-26 8:32 ` stephane eranian
2008-11-26 8:46 ` Ingo Molnar
2008-11-26 9:00 ` Andrew Morton
2008-11-26 9:31 ` Peter Zijlstra
2008-11-26 10:21 ` Ingo Molnar
2008-11-25 10:39 ` Alexander van Heukelum
2008-11-25 15:19 ` stephane eranian
-- strict thread matches above, loose matches on Subject: below --
2008-11-26 4:24 H. Peter Anvin
2008-11-25 10:03 Stephen Rothwell
2008-11-07 8:42 Stephen Rothwell
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=20081126033318.GE8242@elte.hu \
--to=mingo@elte$(echo .)hu \
--cc=a.p.zijlstra@chello$(echo .)nl \
--cc=akpm@linux-foundation$(echo .)org \
--cc=eranian@gmail$(echo .)com \
--cc=heukelum@mailshack$(echo .)com \
--cc=hpa@zytor$(echo .)com \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=tglx@linutronix$(echo .)de \
--cc=x86@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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