Re: Linux 3.9-rc1

Linus Torvalds
2013-03-04T02:55:04Z

On Sun, Mar 3, 2013 at 6:32 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
>
> I suppose that this omits individual contributor patches by design?
> I had 3 patches merged, but they are hidden by this method.

Absolutely.

We had over ten thousand commits in between 3.8 and 3.9-rc1 (10942 if
you count merges, 10265 if you don't). So the whole shortlog format
(that gives authorship for individual commits) is simply not very
useful. It's over half a megabyte of data.

You show up in the shortlog:

Randy Dunlap (5):
lguest: select CONFIG_TTY to build properly.
i2c: fix i2c-ismt.c printk format warning
[SCSI] scsi: fix lpfc build when wmb() is defined as mb()
watchdog: da9055_wdt needs to select WATCHDOG_CORE
hsi: fix kernel-doc warnings

but it's *so* much data that it's not worth posting in lkml. Nobody
would read it, and more importantly, it's so much that there's no feel
for any kind of overview.

The *mergelog* I post is literally just a list of merges I do, and the
names that get credited are neither the authors nor the committers,
but literally just the people who send me the pull request. Now,
*often* that has high correlation with committers, but not always. For
example, David Miller is who asks me to pull the networking tree, but
in reality, that hides not just all the authors, but also all the
submaintainers who he in turn pulls from. Similarly, most of the x86
tree pull requests come from Ingo, even though there are other people
involved as maintainers.

So the mergelog really only gives you an idea of which *subsystems*
got merged, and generally the top-level maintainer for that subsystem.
And even then, the "top-level maintainer" can be just "one of several
top-level maintainers", so even that particular data point is not
really completely unambiguous.

Linus