From: Ingo Molnar <mingo@elte•hu>
To: Andrew Morton <akpm@linux-foundation•org>
Cc: eranian@gmail•com, Stephen Rothwell <sfr@canb•auug.org.au>,
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>
Subject: Re: linux-next: manual merge of the perfmon3 tree
Date: Wed, 26 Nov 2008 11:21:19 +0100 [thread overview]
Message-ID: <20081126102119.GA28112@elte.hu> (raw)
In-Reply-To: <20081126010022.63049908.akpm@linux-foundation.org>
* Andrew Morton <akpm@linux-foundation•org> wrote:
> On Wed, 26 Nov 2008 09:46:04 +0100 Ingo Molnar <mingo@elte•hu> wrote:
>
> > _Especially_ if
> > then the linux-next integrator also plays stupid about basic kernel
> > workflow questions ;-)
>
> He didn't. I suggested to Stephane and Stephen that we get this
> stuff into linux-next for a shot at 2.6.29 and that the collective
> 'we' make an extra effort to get perfmon over the hump and merged
> up.
Did you think of Cc:-ing the affected maintainers, as a basic
courtesy, and to make sure it's aligned up with their next merge
window plans? Inform them to warn them about upcoming conflicts and
other possible trouble you are causing in the code they are
maintaining.
I'm sure you must have noticed the x86 impact from that patchset:
arch/x86/Kconfig | 2 +
arch/x86/Makefile | 3 +
arch/x86/ia32/ia32entry.S | 5 +
arch/x86/include/asm/Kbuild | 1 +
arch/x86/include/asm/irq_vectors.h | 5 +
arch/x86/include/asm/mach-default/entry_arch.h | 4 +
arch/x86/include/asm/perfmon.h | 34 ++
arch/x86/include/asm/perfmon_kern.h | 438 +++++++++++++++++
arch/x86/include/asm/thread_info.h | 8 +-
arch/x86/include/asm/unistd_32.h | 5 +
arch/x86/include/asm/unistd_64.h | 11 +-
arch/x86/kernel/entry_32.S | 2 +-
arch/x86/kernel/entry_64.S | 8 +-
arch/x86/kernel/irqinit_64.c | 5 +
arch/x86/kernel/process_32.c | 10 +
arch/x86/kernel/process_64.c | 10 +
arch/x86/kernel/signal_32.c | 5 +
arch/x86/kernel/signal_64.c | 5 +
arch/x86/kernel/syscall_table_32.S | 5 +
arch/x86/oprofile/nmi_int.c | 10 +-
arch/x86/perfmon/Kconfig | 33 ++
arch/x86/perfmon/Makefile | 7 +
arch/x86/perfmon/perfmon.c | 619 +++++++++++++++++++++++
arch/x86/perfmon/perfmon_amd64.c | 483 ++++++++++++++++++
arch/x86/perfmon/perfmon_intel_arch.c | 628 ++++++++++++++++++++++++
25 files changed, 2340 insertions(+), 6 deletions(-)
There's a ton of RFC patches on lkml that affect x86, it's a naturally
popular arch for various kernel features. Right now there's 4-5 RFC
features on lkml that have an x86 impact. Should we NAK all of them as
a precaution, just to be on the safe side against surprises?
> You missed that email, [...]
to put it into perspective, this is the single mail about this topic
that you are referring to:
http://lkml.org/lkml/2008/10/22/381
you wrote (well into the mail):
| What it needs is a sustained effort to get it over the hump.
| How's about getting it into linux-next asap and then we all agree
| to do the re-re-re-review and runtime testing for a 2.6.29 merge?
That was deep inside an existing discussion, and posed as a question.
The rest is probably private mails between you and sfr, right? No Cc:
to the affected x86 maintainers and without any syncing with the merge
schedule of the affected maintainers. How do you expect us to have
magically deducted what you've done after that point privately?
And what would it have costed you to actually ... ask our opinion? To
make sure everyone is on the same page? Instead of doing this all
privately and behind our backs in essence?
> [...] missed the presence of perfmon in linux-next and repeatedly
> chose to not review the perfmon patch series when it went past.
So every patch that touches lkml and has not specifically been NAK-ed
by maintainers can show up in linux-next tomorrow, overlapping
existing and well-maintained subsystem trees? That's a rather new
concept to me that goes straight again all current maintenance
practices and i think it is an absurd notion. It does not and it
cannot work like that.
Sometimes we maintainers volunteer and review an pick up larger
patches from lkml without being asked to. (we dont actually _have_ to,
but we try to - the influx of patches and the plans for the cycle
_ALWAYS_ has to be synced up with affected maintainers)
Sometimes, especially if a difficult merge is upcoming, we wait for
them to be actively submitted to us and prioritize features based on
review and testing feedback. Especially if it's the 10th version of a
rather complex patchset that seemed to be getting nowhere.
Also, i asked this from you before and have not gotten an answer to it
yet: how am i supposed to follow what goes into linux-next, in an
efficient manner?
linux-next is a huge tree with 4000+ ever changing commits, and it is
not at all transparent in the Git space: a ton of commits get rebased
on a daily basis (all the quilt queues). There's no history of for
example the 'linux-next/master/Trees' file either that would show and
explain when and why trees were added to (or removed from) linux-next.
So linux-next has no proper reviewable history - unless you expect us
to standardize on doing nothing but parsing linux-next changelogs all
day.
_You_ certainly know what goes into linux-next, simply because you are
the one who gets Cc:-ed to everything that goes into it. So you are in
a fundamentally assymetric position. But how can you then expect
symmetric awareness from us?
On the other hand i can and i do monitor what goes into Linus's tree,
because it's a proper append-only Git tree. I can see all the merge
decisions and activities in a very straightforward manner. The same is
not possible with linux-next.
Ingo
next prev parent reply other threads:[~2008-11-26 10:22 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
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 [this message]
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=20081126102119.GA28112@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