Linus,
Please pull the latest x86 git tree from:
   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86/for-linus
this is our first merge window since we migrated over to a pure Git

based patch management setup and integrated x86.git into the -tip tree.

Going from Quilt to Git was quite hard for this

1000-patches-per-kernel-cycle tree, so please bear with us :-)
42 individual x86 topic trees arose in the past development cycle:
 x86/amd-iommu, x86/apic, x86/apm, x86/bitops, x86/build, x86/cleanups,

 x86/core, x86/cpa, x86/cpu, x86/debug, x86/defconfig, x86/delay,

 x86/fixmap, x86/gart, x86/generalize-visws, x86/i8259, x86/idle, x86/intel,

 x86/irq, x86/irqstats, x86/kconfig, x86/ldt, x86/mce, x86/memtest, x86/mmio,

 x86/mpparse, x86/nmi, x86/numa, x86/numa-fixes, x86/oprofile, x86/pat,

 x86/ptemask, x86/ptrace, x86/resumetrace, x86/setup, x86/threadinfo,

 x86/timers, x86/unify-lib, x86/unify-pci, x86/uv, x86/vdso, x86/xen.
.. carrying a total of 820 (non-git-merge) commits from 70 authors.
[ There is one non-x86 topic that was merged into x86/core:

  tip/sysfs/firmware. This is a two-commit feature acked by Greg which had

  dependencies to the e820 changes in x86/core. ]
We hoped to be able to send pull requests for all the topics separately

but near the end of the cycle most of the topics were merged together to

reduce conflicts. We expect this to be different in the next merge

window - topics should be able to survive up to the merge window, and be

mergable in isolation.
Of the 42 topics, 15 have out-of-topic impact, covering 41 commits. All

but 4 of those 41 commits are in linux-next. (those 4 commits are simply

fresh and will be in the next iteration of linux-next)
Here's a (semi-)automated output of which topic created what type of

generic impact:
out-of-topic modifications in x86/xen:

--------------------------------------

drivers/lguest/lg.h                # a15af1c: x86/paravirt: add pte_flags to ju

include/asm-generic/pgt...
[ message continues ]

Hi,
I see that fix patches are no longer folded into the guilty patch

and it makes me a bit worried about kernel bisectability (on which

many people depend on for hunting regressions)...
Random example (amongst many others) of what I mean:
There is also a _ton_ of build fixes which could have been easily

folded into guilty patches.
Could you please consider adding this additional step into your

development process before push to Linus?
Thanks,

Bart

--

actually, while there are indeed other examples where merging fixes

would have made sense, those 3 above are conceptually different so we 
yeah, we definitely try to do that but -tip is released daily so the

window to squash patches is small in an append-only setup. There were 2

days between those fixes above so even if we wanted we couldnt squash

them. The purpose of finegrained fixes is to observe the effects of the

fixes. (sometimes the fix is worse than the bug it purports to fix)
Anyway, i think you'll see less of these in the next merge window.
	Ingo

--

On Mon, Jul 14, 2008 at 03:50:35PM +0200, Ingo Molnar wrote:

 > Linus,

 >

 > Please pull the latest x86 git tree from:

 >

 >    git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86/for-linus

 >

 > this is our first merge window since we migrated over to a pure Git

 > based patch management setup and integrated x86.git into the -tip tree.

 > Going from Quilt to Git was quite hard for this

 > 1000-patches-per-kernel-cycle tree, so please bear with us :-)

 >

 > 42 individual x86 topic trees arose in the past development cycle:

 >

 >  x86/amd-iommu, x86/apic, x86/apm, x86/bitops, x86/build, x86/cleanups,

 >  x86/core, x86/cpa, x86/cpu, x86/debug, x86/defconfig, x86/delay,

 >  x86/fixmap, x86/gart, x86/generalize-visws, x86/i8259, x86/idle, x86/intel,

 >  x86/irq, x86/irqstats, x86/kconfig, x86/ldt, x86/mce, x86/memtest, x86/mmio,

 >  x86/mpparse, x86/nmi, x86/numa, x86/numa-fixes, x86/oprofile, x86/pat,

 >  x86/ptemask, x86/ptrace, x86/resumetrace, x86/setup, x86/threadinfo,

 >  x86/timers, x86/unify-lib, x86/unify-pci, x86/uv, x86/vdso, x86/xen.

 >

 > .. carrying a total of 820 (non-git-merge) commits from 70 authors.
Wow.
6924d1ab8b7bbe5ab416713f5701b3316b2df85b is a work of art.

Is it ascii-art tetris? a magic eye picture? you decide!
It looks even more spectacular in gitk.
	Dave
--

http://www.codemonkey.org.uk

--

heh, thanks :)
Being able to shuffle around independent topics and only sending those

which were ready was the single biggest advantage that quilt had for us.

So we tried hard to keep the same workflow property under git as well.

We were sceptical in the beginning due to git's fundamental append-only

nature but after a ton of scripting by Thomas and me it turned out to be

doable under git as well.
In hindsight going to a pure git workflow worked out pretty well i think

and Linus was right when he suggested that we'd be happier with a pure

git workflow. We are now roughly back to the same speed and reliability

of processing incoming patches as we were under quilt with the

monolothic x86 and sched-devel trees and the end result is (much) more

structured so it's a marked improvement.
... so we've got all the advantages of a quilt workflow, and all the

advantages of git as well, combined. Scripted per topic progress reports

like the one below were unthinkable under quilt. So there's no looking

back :-)
	Ingo
-------------------------------------------------------------------->

earth4:~/tip> tip-pending
topic                                   #commits

------------------------------------------------

acpi-for-len                            :      2

core/futex-64bit                        :      1

core/generic-dma-coherent               :      1

core/kill-the-BKL                       :     18

core/misc                               :      2

core/percpu                             :      3

core/percpu-zerobased                   :      4

core/softlockup                         :      8

core/warn-API                           :     15

cpus4096                                :     13

kmemcheck                               :     20

out-of-tree                             :     16

pci-for-jesse                           :      1

safe-poison-pointers                    :      1

stackprotector                          :     18

timers/hpet                  ...
[ message continues ]

Here's how to search for those with git:
	git rev-list --all --parents | egrep '( .*){10}' | cut -d' ' -f1
will show you all commits with ten or more parents (although some of them

have duplicate parents due to git historically not checking that very

carefully).
Len and rmk have been doing it for a while, but yeah, I think Ingo pushed

the envelope there a bit.
But 96916090f488986a4ebb8e9ffa6a3b50881d5ccd is pretty nice too, doncha

think?
		Linus

--

Things like this _really_ irritate me:
	Memtest (MEMTEST) [Y/n/?] (NEW) ?
why the hell is that defaulting to "on"?
The rule of thumb should be:
	NO NEW FEATURES SHOULD _EVER_ DEFAULT TO 'ON'!
I do realize that developers always think that _their_ particular cool new

feature is so important that it should default to 'on', but that's always

the case, and it's _always_ wrong.
The only really acceptable reason to add a new config feature and make it

default to 'y' is that it's actually an old feature that just didn't have

a config option, so not defaulting to it will actually break peoples

existing configurations.
If some distro wants to enable features by default for their users, that's

their issue. But we should not do it for them.
		Linus

--

.. and now I get all the FTRACE stuff _individually_, with MMIOTRACE

(which is likely the _least_ interesting one for any normal person) being

turned on by default.
Ingo, you _really_ need to look at those Kconfig options. They're insane.
		Linus

--

... sorry about that - will send patches later today for all default-y

stuff that slipped through.
default-y is handy for the development period, and i usually turn it off

when it's close to go upstream (like i made stackprotector default-off),

but things slip through ...
	Ingo

--

I'm a bit surprised that you'd say that for something that is a

hardware-testing feature that needs a command-line option to be enabled

at runtime.  I have always presumed that the default value is the

recommended value, and I would think that that is what most people would

assume.
	-hpa

--

No. The default value should be 'off', unless it's _needed_ by people.
Have you guys looked at the size of the kernel lately?
Bloat is bloat. Just because it's conditional is not an excuse.
Having an in-kernel memory tester is in no way better than having an

out-of-kernel one that you pick at grub boot time, so the claim that it's

a "recommended" thing is likely bogus too. 
		Linus

--

Btw, the reason I reacted was that that wasn't even the only one.
It was followed by that MTRR "cleanup" question, which also defaulted to

'y', despite:
 - having a help message that warned about oopses and problems
 - answering 'y' then caused a follow-up of totally incomprehensible and

   meaningless options with no help message what-so-ever.
Dammit, if _I_ find the option to be badly named, confusing, unnecessary

and undocumented, maybe it should be a clue to somebody that it probably

shouldn't exist, much less default to 'sure, do that crazy thing'.
(I think there was something else, but by then I didn't care any more, and

just said no without even looking at the insane crap)
			Linus

--

Fair enough.
	-hpa

--