Subject: Re: linux-next: manual merge of the perfmon3 tree

From: Ingo Molnar <[email-masked]>
Date: Wed, 26 Nov 2008 11:21:19 +0100

* Andrew Morton <[email-masked]> wrote:

> On Wed, 26 Nov 2008 09:46:04 +0100 Ingo Molnar <[email-masked]> 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