* Linux 3-10-rc1
@ 2013-05-12 1:00 Linus Torvalds
2013-05-12 1:32 ` Chris Jones
2013-05-13 1:18 ` linux-next stats (Was: Linux 3-10-rc1) Stephen Rothwell
0 siblings, 2 replies; 4+ messages in thread
From: Linus Torvalds @ 2013-05-12 1:00 UTC (permalink / raw)
To: Linux Kernel Mailing List
So this is the biggest -rc1 in the last several years (perhaps ever)
at least as far as counting commits go, even if not necessarily in
actual lines (I didn't check the statistics on that).
Which was unexpected, because while linux-next was fairly big, it
wasn't exceptionally so. I'm sure Stephen Rothwell will talk about the
statistics of commits that weren't in -next, we'll see if that was the
reason..
Anyway, despite the large number of commits, hopefully it's all
boringly straigthforward. Sure.
Now, even normally, there's no way to list all the changes, much less
so when it's an unusually large -rc1. But I can do my "merge shortlog"
again, and it's worth mentioning (again) that the name attributed to
the merge is *not* necessarily the author of any of the code, it's
literally just the person who emailed me the pull request. So you can
see this as an approximation of "first-level maintainership" or
something, although even that is somewhat misleading since some of
these things are really done by groups and then there's one person who
end up sending me the end result.
But it's somewhat readable, and gives you a reasonable idea of what is
going on. A better idea can be gotten by looking at git directly,
especially since the merge commits often do contain a better
description of what happened. Not that all submaintainers necessarily
always send me that, but most of the merges actually do have
human-readable background information.
It's possible that I missed something. This really was a busier merge
window than usual. Holler if so,
Linus
---
Al Viro: (7)
VFS updates
compat cleanup
second round of VFS updates
single_open() leak fixes
more vfs updates
more vfs fixes
stray syscall bits
Alasdair Kergon: (1)
device-mapper updates
Alex Elder: (1)
Ceph changes
Alex Williamson: (1)
vfio updates
Andrew Morton: (5)
first batch of fixes
second batch of fixes
third batch of fixes
IPC cleanup and scalability patches
more incoming
Anton Vorontsov: (2)
battery updates
pstore update
Arnd Bergmann: (5)
ARM SoC platform updates (part 2)
ARM SoC platform updates (part 3)
ARM SoC device tree updates (part 2)
ARM SoC late cleanups
late ARM Exynos multiplatform changes
Ben Myers: (2)
xfs update
xfs update (#2)
Benjamin Herrenschmidt: (2)
powerpc update
powerpc updates
Bjorn Helgaas: (2)
PCI updates
PCI updates
Borislav Petkov: (1)
two small EDAC fixes
Bruce Fields: (1)
nfsd fixes
Bryan Wu: (1)
LED subsystem updates
Catalin Marinas: (2)
arm64 update
arm64 update
Chris Ball: (1)
MMC update
Chris Mason: (1)
btrfs update
Chris Metcalf: (2)
tile arch changes
tile update
Chris Zankel: (1)
xtensa updates
Dave Airlie: (1)
drm updates
David Kleikamp: (1)
jfs fixes
David Miller: (5)
networking updates
sparc updates
networking fixes
networking fixes
networking update
David Teigland: (1)
dlm update
David Woodhouse: (2)
MTD update
misc fixes
Dmitry Torokhov: (1)
input updates
Eric Paris: (1)
audit changes
Geert Uytterhoeven: (1)
m68k update
Gleb Natapov: (2)
kvm updates
kvm fixes
Grant Likely: (2)
GPIO changes
removal of GENERIC_GPIO
Greg Kroah-Hartman: (5)
char/misc driver update
driver core update
staging driver tree update
tty/serial driver update
USB patches
Greg Ungerer: (1)
m68knommu updates
Guenter Roeck: (1)
hwmon update
Helge Deller: (1)
parisc updates
Herbert Xu: (1)
crypto update
Ingo Molnar: (18)
locking changes
RCU updates
perf updates
scheduler changes
SMP/hotplug changes
core timer updates
extable dmesg fixlet
x86 cleanups
x86 cpuid changes
x86 debug update
perparatory x86 kasrl changes
x86 mm changes
x86 paravirt update
x86 platform changes
x86 RAS changes
scheduler fixes
perf fixes
'full dynticks' support
J Bruce Fields: (1)
nfsd changes
Jaegeuk Kim: (1)
f2fs updates
James "Jej B" Bottomley: (2)
first round of SCSI updates
second SCSI update
James Hogan: (1)
arch/metag update
James Morris: (1)
security subsystem update
Jan Kara: (1)
ext3/jbd fixes
Jean Delvare: (1)
hwmon update
Jeff Garzik: (1)
libata update
Jens Axboe: (2)
block core updates
block driver updates
Jiri Kosina: (4)
trivial tree updates
HID updates
fixup for trivial branch
HID fixes
Joerg Roedel: (1)
IOMMU updates
Konrad Rzeszutek Wilk: (2)
Xen updates
Xen bug-fixes
Len Brown: (1)
idle update
Linus Walleij: (2)
pinctrl update
pinctrl fixes
Mark Brown: (3)
regmap updates
regulator updates
spi updates
Martin Schwidefsky: (2)
s390 update
more s390 updates
Matthew Garrett: (1)
x86 platform drivers
Matthew Wilcox: (1)
NVMe driver update
Mauro Carvalho Chehab: (3)
media update
edac fixes
omap3isp clk support
Michael Tsirkin: (2)
vhost cleanups and fixes
more vhost fixes
Michael Turquette: (1)
clock framework update
Michal Marek: (3)
kbuild changes
kconfig updates
misc kbuild updates
Michal Simek: (1)
microblaze updates
Michel Lespinasse: (1)
rwsem optimizations
Miklos Szeredi: (1)
fuse updates
my IPC branch: (1)
ipc fixes and cleanups
NeilBrown: (1)
md fixes
Nicholas Bellinger: (1)
SCSI target update
Ohad Ben-Cohen: (2)
rpmsg changes
remoteproc update
Olof Johansson: (10)
ARM SoC non-critical fixes
ARM SoC cleanup
ARM SoC device-tree updates
ARM SoC platform updates
ARM SoC multiplatform updates
ARM SoC driver changes
ARM SoC pinctrl changes for Renesas
ARM platform specific firmware interfaces
ARM SoC board specific changes (part 1)
ARM SoC fixes and straggler patches
Pekka Enberg: (1)
slab changes
Peter Anvin: (2)
x86/efi changes
x86 fixes
Rafael J Wysocki: (1)
power management and ACPI updates
Rafael Wysocki: (1)
ACPICA fixes
Ralf Baechle: (1)
MIPS updates
Richard Kuo: (2)
Hexagon fixes
Hexagon fixes
Roland Dreier: (1)
InfiniBand/RDMA changes
Russell King: (1)
ARM updates
Rusty Russell: (2)
virtio & lguest updates
mudule updates
Samuel Ortiz: (1)
MFD update
Sarah Sharp: (1)
ReportingBugs rewrite
Stefan Richter: (1)
firewure updates
Stefano Stabellini: (1)
ARM Xen SMP updates
Steve French: (1)
CIFS fixes
Steven Miao: (1)
blackfin updates
Steven Rostedt: (4)
tracing updates
ktest update
localmodconfig changes
tracing/kprobes update
Steven Whitehouse: (1)
GFS2 updates
Sumit Semwal: (1)
dma-buf updates
Takashi Iwai: (2)
sound updates
sound fixes
Ted Ts'o: (1)
ext4 updates
Tejun Heo: (5)
percpu patch
async update
workqueue updates
cgroup updates
libata maintainership change
Thierry Reding: (1)
pwm changes
Tomi Valkeinen: (1)
fbdev updates
Tony Luck: (2)
ia64 fixes
trivial pstore update
Trond Myklebust: (2)
NFS client bugfixes and cleanups
more NFS client bugfixes
Tyler Hicks: (1)
eCryptfs update
Vineet Gupta: (2)
ARC port updates
second set of arc arch updates
Vinod Koul: (1)
slave-dmaengine updates
Wim Van Sebroeck: (1)
watchdog update
Wolfram Sang: (1)
i2c changes
Zhang Rui: (1)
thermal management update
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Linux 3-10-rc1
2013-05-12 1:00 Linux 3-10-rc1 Linus Torvalds
@ 2013-05-12 1:32 ` Chris Jones
2013-05-13 1:18 ` linux-next stats (Was: Linux 3-10-rc1) Stephen Rothwell
1 sibling, 0 replies; 4+ messages in thread
From: Chris Jones @ 2013-05-12 1:32 UTC (permalink / raw)
To: linux-kernel; +Cc: Linus Torvalds
On 05/12/2013 11:00 AM, Linus Torvalds wrote:
> So this is the biggest -rc1 in the last several years (perhaps ever)
> at least as far as counting commits go, even if not necessarily in
> actual lines (I didn't check the statistics on that).
>
> Which was unexpected, because while linux-next was fairly big, it
> wasn't exceptionally so. I'm sure Stephen Rothwell will talk about the
> statistics of commits that weren't in -next, we'll see if that was the
> reason..
>
> Anyway, despite the large number of commits, hopefully it's all
> boringly straigthforward. Sure.
>
> Now, even normally, there's no way to list all the changes, much less
> so when it's an unusually large -rc1. But I can do my "merge shortlog"
> again, and it's worth mentioning (again) that the name attributed to
> the merge is *not* necessarily the author of any of the code, it's
> literally just the person who emailed me the pull request. So you can
> see this as an approximation of "first-level maintainership" or
> something, although even that is somewhat misleading since some of
> these things are really done by groups and then there's one person who
> end up sending me the end result.
>
> But it's somewhat readable, and gives you a reasonable idea of what is
> going on. A better idea can be gotten by looking at git directly,
> especially since the merge commits often do contain a better
> description of what happened. Not that all submaintainers necessarily
> always send me that, but most of the merges actually do have
> human-readable background information.
>
> It's possible that I missed something. This really was a busier merge
> window than usual. Holler if so,
>
> Linus
>
> <snip>
Thanks for the summary of changes. That helps.
Regards
Chris Jones
--
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.13 (GNU/Linux)
mQENBFF7bwcBCADREEkM0EcEvY6Zt3Zot5RWk5+a6qMZzj6Qf8tZnG2mjyb/NrOa
ujQhakpkmUj2Cpf04jacEKnjxO5Bk6794QPoSelHAkLFol9XRO6j+94tp+21mrGL
GRHppU8LGGCTrllIJOmKdx2dmqIfYKoRcLs/gA1z0ZrNNz+J3OrcWfDWfVz0eWg6
TeXn4PBAQYr8Ci1fF9/vwxeSQx3PGzJjlzKXsbx/etjICDVVkUAxYkEPbazV1LGx
gwDlhCT5YWQQXdESIbUkQFAbCyglM/HkMNEm23AI/z4PhgjdHBCg8LeQTEUiO+a+
b1ypRMZRpn/je96/PE1ZP5TxaEhaimL+OA+dABEBAAG0JENocmlzIEpvbmVzIDxj
aHJpc2pvbmVzQHNwaW4ubmV0LmF1PokBPgQTAQIAKAUCUXtvBwIbAwUJACdPGQYL
CQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQxifpw+rbaJQQBwf+M+arauGqAtkA
LP3Duk0FdDZ3cIbKST3oQd10eACdkH7fQibvtVadkiCeC7CbozSI50o+Snk8/Azd
5V32LkmzUcUEGrnx3B9oZlWMSKZFz5y1rN0YiplQwc4KLq1cSYOZFpVHUZ/ivcJn
k+p+cuLWQrNUI5kiFV+x6lOKIkKgmMrmuKxbwYskPPtE1DIJ7Qh8H/N9aTJ34KAD
+O4dMwDlA2dYDoQYmyCMcly6W6NdPQmww1XX5qmY+obokScIJE5mYUyiFz0kiN6C
NsosjMsUxbrNEPjAfzyU5Y+LqffYJzgyTjlORRqldZU6IDhsmtyDBoshGQFAEm6W
dRQOrNYx6A==
=FJFi
-----END PGP PUBLIC KEY BLOCK-----
^ permalink raw reply [flat|nested] 4+ messages in thread
* linux-next stats (Was: Linux 3-10-rc1)
2013-05-12 1:00 Linux 3-10-rc1 Linus Torvalds
2013-05-12 1:32 ` Chris Jones
@ 2013-05-13 1:18 ` Stephen Rothwell
2013-05-13 5:05 ` Benjamin Herrenschmidt
1 sibling, 1 reply; 4+ messages in thread
From: Stephen Rothwell @ 2013-05-13 1:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, linux-next, Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 2612 bytes --]
On Sat, 11 May 2013 18:00:09 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> So this is the biggest -rc1 in the last several years (perhaps ever)
ever (see http://neuling.org/linux-next-size.html after today's
linux-next release).
> Which was unexpected, because while linux-next was fairly big, it
> wasn't exceptionally so. I'm sure Stephen Rothwell will talk about the
> statistics of commits that weren't in -next, we'll see if that was the
> reason..
Since you asked ... :-)
This was the second biggest linux-next ever (in terms of commits) the one
before v3.8 was somewhat larger).
(No merge commits counted, next-20130429 was the last linux-next before v3.9)
Commits in v3.10-rc1 (relative to v3.9): 11963
Commits in next-20130429: 11300
Commits with the same SHA1: 9708
Commits with the same patch_id: 885 (1)
Commits with the same subject line: 91 (1)
(1) not counting those in the lines above.
So commits in -rc1 that were "in" next-20130429: 10684 89.3%
(down from 90.6% last time)
Commits in -rc1 that were not in next-20120722: 1279 10.7%
Pretty good, but it would be still nice to figure out where the last lot
came from. I have the "git log --oneline --no-walk" list if someone wants them.
Some breakdown of that list:
Top ten first word of commit summary:
27 NVMe
29 xfs
41 drm
47 powerpc
59 rbd
64 arm
78 media
84 mips
92 SCSI
101 btrfs
Top ten authors:
19 Wang Shilong <wangsl-fnst@cn.fujitsu.com>
19 Wei Yongjun <yongjun_wei@trendmicro.com.cn>
21 Dave Chinner <dchinner@redhat.com>
22 James Smart <james.smart@emulex.com>
25 John Crispin <blogic@openwrt.org>
26 Steven J. Hill <Steven.Hill@imgtec.com>
28 Josef Bacik <jbacik@fusionio.com>
31 Hans Verkuil <hans.verkuil@cisco.com>
35 Al Viro <viro@zeniv.linux.org.uk>
64 Alex Elder <elder@inktank.com>
Top ten commiters:
29 Ben Myers <bpm@sgi.com>
43 Al Viro <viro@zeniv.linux.org.uk>
44 Benjamin Herrenschmidt <benh@kernel.crashing.org>
54 Sage Weil <sage@inktank.com>
59 Linus Torvalds <torvalds@linux-foundation.org>
80 Mauro Carvalho Chehab <mchehab@redhat.com>
87 Ralf Baechle <ralf@linux-mips.org>
92 James Bottomley <JBottomley@Parallels.com>
99 Josef Bacik <jbacik@fusionio.com>
111 David S. Miller <davem@davemloft.net>
Quite a few of these could be bug fixes (especially DaveM's).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: linux-next stats (Was: Linux 3-10-rc1)
2013-05-13 1:18 ` linux-next stats (Was: Linux 3-10-rc1) Stephen Rothwell
@ 2013-05-13 5:05 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 4+ messages in thread
From: Benjamin Herrenschmidt @ 2013-05-13 5:05 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linus Torvalds, Linux Kernel Mailing List, linux-next,
Andrew Morton
On Mon, 2013-05-13 at 11:18 +1000, Stephen Rothwell wrote:
> 47 powerpc
Oops ;-)
So most of that *was* in -next for at least a day or two afaik just not
before the merge window opened. The reason for that is that I was on
an extended vacation for 5 weeks and was playing catch up until fairly
late, almost all of these are either bug fixes or things that were
posted for a while, reviewed and just hadn't been picked up due to the
lack of a maintainer. (Michael was my backup but he was busy getting
married :-)
Cheers,
Ben.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-05-13 5:05 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-05-12 1:00 Linux 3-10-rc1 Linus Torvalds
2013-05-12 1:32 ` Chris Jones
2013-05-13 1:18 ` linux-next stats (Was: Linux 3-10-rc1) Stephen Rothwell
2013-05-13 5:05 ` Benjamin Herrenschmidt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox