* Linux 3.13-rc1 is out
@ 2013-11-22 20:36 Linus Torvalds
2013-11-23 0:43 ` Matthew Garrett
` (3 more replies)
0 siblings, 4 replies; 7+ messages in thread
From: Linus Torvalds @ 2013-11-22 20:36 UTC (permalink / raw)
To: Linux Kernel Mailing List
So you had an extra week to prepare your pull requests, and if you
were planning on sending it in the last two days thinking I'd close
the merge window on Sunday as usual, I can only laugh derisively in
your general direction, and call you bad names. Because I'm not
interested in your excuses. I did warn people about this in the 3.12
release notes. As it was, there were a few people who cut it fairly
close today. You know who you are.
If there are pull requests I missed (due to getting caught in spam
filters, or not matching my normal search patterns), and you think you
sent your pull request in time but it got overlooked, ping me -
because I don't have anything pending I know about, but mistakes
happen.
Talking about mistakes... I suspect it was a mistake to have that
extra week before the merge window opened, and I probably should just
have done a 3.12-rc8 instead. Because the linux-next statistics look
suspicious, and we had extra stuff show up there not just in that
first week. Clearly people took that "let's have an extra week of
merge window" and extrapolated it a bit too much. Oh, well. Live and
learn.
Anyway, other than that small oddity, this was a fairly normal merge
window. By patch size we had a pretty usual ~55% drivers, 18%
architecture code, 9% network updates, and the rest is spread out (fs,
headers, tools, documentation). Featurewise, the big ones are likely
the nftables and the multi-queue block layer stuff, but depending on
your interests you might find all the incremental updates to various
areas interesting. There are some odd ones in there (LE mode Powerpc
support..)
Go forth and test, and start sending me regression fixes. And really,
if you didn't send me your pull request in time, don't whine about it.
Because nobody likes a whiner.
Shortlog of merges appended. The real shortlog is much too big to be
readable, as always for rc1.
Linus
---
Al Viro (3):
vfs updates
VFS fixes
vfs bits and pieces
Andrew Morton (3):
first patch-bomb
patches
patches
Anton Vorontsov (1):
battery updates
Artem Bityutskiy (2):
ubifs changes
UBI changes
Ben Myers (2):
xfs update
second xfs update
Benjamin Herrenschmidt (3):
powerpc updates
powerpc LE updates
third set of powerpc updates
Benjamin LaHaise (1):
aio fixes
Bjorn Helgaas (2):
PCI changes
PCI updates
Borislav Petkov (1):
EDAC updates
Brian Norris (1):
MTD changes
Bruce Fields (2):
nfsd changes
nfsd bugfixes
Bryan Wu (1):
LED subsystem changes
Catalin Marinas (1):
ARM64 update
Chris Ball (1):
MMC updates
Chris Mason (2):
btrfs fixes
btrfs fixes
Dave Airlie (3):
drm updates
drm regression fix
DRM fixes
David Miller (7):
networking fixes
networking updates
sparc update
IDE updates
sparc fixes
networking fixes
networking fixes
David Teigland (1):
dlm fix
Dmitry Torokhov (1):
input updates
Eric Paris (1):
audit updates
Geert Uytterhoeven (1):
m68k updates
Gleb Natapov (1):
KVM fixes
Greg KH (5):
USB driver update
char/misc patches
driver core / sysfs patches
tty/serial driver updates
staging driver update
Guenter Roeck (3):
h8300 platform removal
hwmon updates
hwmon fixes
Hans-Christian Egtvedt (1):
AVR32 updates
Helge Deller (2):
parisc update
parisc fixes
Ingo Molnar (30):
RCU updates
IRQ changes
leftover IRQ fixes
perf updates
scheduler changes
timer changes
x86/apic fix
x86 user access changes
x86 boot changes
x86 build changes
x86 cleanups
x86 cpu changes
x86 EFI changes
x86/hyperv changes
x86/intel-mid changes
x86 iommu changes
x86 RAS changes
x86 mm fixlet
x86 platform fixlet
x86 reboot changes
x86 uaccess changes
x86 UV debug changes
x86/trace changes
core locking changes
scheduler fixes
two x86 fixes
perf updates
perf fixes
irq cleanups
x86 fix
Jaegeuk Kim (1):
f2fs updates
James Bottomley (1):
first round of SCSI updates
James Hogan (1):
metag architecture changes
James Morris (1):
security subsystem updates
Jan Kara (1):
ext[23], udf and quota fixes
Jean Delvare (1):
hwmon fixes and updates
Jens Axboe (4):
block IO core updates
block driver updates
second round of block driver updates
block IO fixes
Jiri Kosina (2):
trivial tree updates
HID updates
Joerg Roedel (1):
IOMMU updates
Jonas Bonn (1):
OpenRISC updates
Konrad Rzeszutek Wilk (1):
Xen updates
Linus Walleij (2):
pin control updates
GPIO changes
Mark Brown (3):
regmap updates
regulator updates
spi updates
Mark Salter (1):
Kconfig cleanups
Martin Schwidefsky (2):
s390 updates
second set of s390 patches
Matt Turner (1):
alpha updates
Mauro Carvalho Chehab (3):
EDAC driver updates
media updates
media build fixes
Michal Marek (3):
kbuild changes
kconfig changes
misc kbuild changes
Michal Simek (1):
microblaze updates
Mike Snitzer (1):
device mapper changes
Mike Turquette (1):
clock framework changes
Miklos Szeredi (1):
fuse updates
Neil Brown (1):
md update
Nicholas Bellinger (1):
SCSI target updates
Olof Johansson (7):
ARM SoC low-priority fixes
ARM SoC cleanups
ARM SoC platform changes
ARM SoC board updates
ARM driver updates
ARM SoC DT updates
ARM SoC fixes
Paolo Bonzini (1):
KVM changes
Pekka Enberg (1):
SLAB changes
Phillip Lougher (1):
squashfs updates
Rafael J Wysocki (1):
ACPI and power management updates
Rafael Wysocki (1):
more ACPI and power management updates
Ralf Baechle (1):
MIPS updates
Richard Weinberger (1):
UML changes
Rob Herring (1):
devicetree updates
Roland Dreier (1):
infiniband/rdma updates
Russell King (3):
DMA mask updates
ARM updates
ARM fixes
Rusty Russell (2):
module updates
virtio updates
Samuel Ortiz (1):
MFD updates
Steve French (2):
CIFS updates
CIFS fixes
Steven Miao (1):
blackfin updates
Steven Rostedt (2):
perf/ftrace fix
tracing update
Steven Whitehouse (2):
gfs2 updates
GFS2 fixes
Takashi Iwai (3):
sound updates
sound fixes
second set of sound fixes
Ted Ts'o (2):
ext4 changes
/dev/random changes
Tejun Heo (3):
percpu changes
libata changes
cgroup changes
Thierry Reding (1):
pwm changes
Tomi Valkeinen (1):
fbdev changes
Tony Luck (1):
ia64 fix
Trond Myklebust (1):
NFS client updates
Tyler Hicks (1):
minor eCryptfs fix
Vineet Gupta (2):
ARC changes
second set of ARC changes
Vinod Koul (1):
slave-dmaengine changes
Wim Van Sebroeck (1):
watchdog changes
Wolfram Sang (1):
i2c changes
Zhang Rui (1):
thermal management updates
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux 3.13-rc1 is out
2013-11-22 20:36 Linux 3.13-rc1 is out Linus Torvalds
@ 2013-11-23 0:43 ` Matthew Garrett
2013-11-23 1:08 ` Linus Torvalds
2013-11-23 0:51 ` James Cloos
` (2 subsequent siblings)
3 siblings, 1 reply; 7+ messages in thread
From: Matthew Garrett @ 2013-11-23 0:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
Hi Linus,
I'd sent a pull yesterday (http://lkml.org/lkml/2013/11/21/599 ) which
may have missed your cutoff, but it seems worth checking.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux 3.13-rc1 is out
2013-11-22 20:36 Linux 3.13-rc1 is out Linus Torvalds
2013-11-23 0:43 ` Matthew Garrett
@ 2013-11-23 0:51 ` James Cloos
2013-11-23 2:32 ` Jongman Heo
2013-11-23 0:58 ` Shuah Khan
2013-11-25 0:10 ` linux-next stats (Was: Linux 3.13-rc1 is out) Stephen Rothwell
3 siblings, 1 reply; 7+ messages in thread
From: James Cloos @ 2013-11-23 0:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
This combination:
# CONFIG_SYSTEM_TRUSTED_KEYRING is not set
CONFIG_TRUSTED_KEYS=m
(acquired by oldconfig and N to system keyring)
fails with:
Pass 2
CC [M] crypto/asymmetric_keys/x509_rsakey-asn1.o
CC [M] crypto/asymmetric_keys/x509_cert_parser.o
CC [M] crypto/asymmetric_keys/x509_public_key.o
crypto/asymmetric_keys/x509_public_key.c: In function ‘x509_key_preparse’:
crypto/asymmetric_keys/x509_public_key.c:237:35: error: ‘system_trusted_keyring’ undeclared (first use in this function)
ret = x509_validate_trust(cert, system_trusted_keyring);
^
crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [crypto/asymmetric_keys/x509_public_key.o] Error 1
make[1]: *** [crypto/asymmetric_keys] Error 2
make: *** [crypto] Error 2
Perhaps include/keys/system_keyring.h should have a definition for
system_trusted_keyring in the #ifndef CONFIG_SYSTEM_TRUSTED_KEYRING
case (which may entail just removing the #ifdef).
Commits b56e5a17b6b9acd1 and 09fbc47373826d67 are relevant.
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux 3.13-rc1 is out
2013-11-22 20:36 Linux 3.13-rc1 is out Linus Torvalds
2013-11-23 0:43 ` Matthew Garrett
2013-11-23 0:51 ` James Cloos
@ 2013-11-23 0:58 ` Shuah Khan
2013-11-25 0:10 ` linux-next stats (Was: Linux 3.13-rc1 is out) Stephen Rothwell
3 siblings, 0 replies; 7+ messages in thread
From: Shuah Khan @ 2013-11-23 0:58 UTC (permalink / raw)
To: Linus Torvalds, Linux Kernel Mailing List, Shuah Khan, shuahkhan
On 11/22/2013 01:36 PM, Linus Torvalds wrote:
> So you had an extra week to prepare your pull requests, and if you
> were planning on sending it in the last two days thinking I'd close
> the merge window on Sunday as usual, I can only laugh derisively in
> your general direction, and call you bad names. Because I'm not
> interested in your excuses. I did warn people about this in the 3.12
> release notes. As it was, there were a few people who cut it fairly
> close today. You know who you are.
>
> If there are pull requests I missed (due to getting caught in spam
> filters, or not matching my normal search patterns), and you think you
> sent your pull request in time but it got overlooked, ping me -
> because I don't have anything pending I know about, but mistakes
> happen.
>
> Talking about mistakes... I suspect it was a mistake to have that
> extra week before the merge window opened, and I probably should just
> have done a 3.12-rc8 instead. Because the linux-next statistics look
> suspicious, and we had extra stuff show up there not just in that
> first week. Clearly people took that "let's have an extra week of
> merge window" and extrapolated it a bit too much. Oh, well. Live and
> learn.
>
> Anyway, other than that small oddity, this was a fairly normal merge
> window. By patch size we had a pretty usual ~55% drivers, 18%
> architecture code, 9% network updates, and the rest is spread out (fs,
> headers, tools, documentation). Featurewise, the big ones are likely
> the nftables and the multi-queue block layer stuff, but depending on
> your interests you might find all the incremental updates to various
> areas interesting. There are some odd ones in there (LE mode Powerpc
> support..)
>
> Go forth and test, and start sending me regression fixes. And really,
> if you didn't send me your pull request in time, don't whine about it.
> Because nobody likes a whiner.
>
3.13-rc1 fails to boot on Samsung Series 9. 3.12.1 is fine and the last
mainline kernel that worked on it was from Nov 14th. It failed to mount
/boot and after doing a manually mounting it, it came up and didn't
detect USB mouse. Looking at the dmesg differences in dmesg, looks like
usb probe fails on USB mouse. I will start a bisect and let you know
what I find.
dmesg 3.13-rc1:
63.637083] PM: Adding info for usb:2-1:1.0
[ 63.637128] driver: '2-1': driver_bound: bound to device 'usb'
[ 63.637136] bus: 'usb': really_probe: bound device 2-1 to driver usb
[ 123.660457] usb 2-1: USB disconnect, device number 3
[ 123.660505] bus: 'usb': remove device 2-1:1.0
[ 123.660508] PM: Removing info for usb:2-1:1.0
[ 123.661718] bus: 'usb': remove device 2-1
[ 123.661724] PM: Removing info for usb:2-1
[ 125.143833] usb 2-1: new low-speed USB device number 4 using xhci_hcd
[ 125.190924] usb 2-1: New USB device found, idVendor=17ef, idProduct=6019
[ 125.190928] usb 2-1: New USB device strings: Mfr=0, Product=2,
SerialNumber=0
[ 125.190930] usb 2-1: Product: Lenovo Optical USB Mouse
[ 125.191042] bus: 'usb': add device 2-1
[ 125.191054] PM: Adding info for usb:2-1
[ 125.191081] bus: 'usb': driver_probe_device: matched device 2-1 with
driver usb
[ 125.191084] bus: 'usb': really_probe: probing driver usb with device 2-1
[ 125.191097] usb 2-1: ep 0x81 - rounding interval to 64 microframes,
ep desc says 80 microframes
[ 125.201952] bus: 'usb': add device 2-1:1.0
[ 125.201959] PM: Adding info for usb:2-1:1.0
[ 125.202010] driver: '2-1': driver_bound: bound to device 'usb'
[ 125.202019] bus: 'usb': really_probe: bound device 2-1 to driver usb
dmesg 3.12.1:
[ 5.562700] bus: 'usb': add driver usbhid
[ 5.562790] bus: 'usb': driver_probe_device: matched device 2-1:1.0
with driv
er usbhid
[ 5.562794] bus: 'usb': really_probe: probing driver usbhid with
device 2-1:1
.0
[ 5.575965] driver: '2-1:1.0': driver_bound: bound to device 'usbhid'
[ 5.575971] bus: 'usb': really_probe: bound device 2-1:1.0 to driver
usbhid
[ 5.575998] usbcore: registered new interface driver usbhid
[ 5.576000] usbhid: USB HID core driver
[ 5.601326] input: Lenovo Optical USB Mouse as
/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/usb2/2-1/2-1:1.0/input/input6
[ 5.601796] hid-generic 0003:17EF:6019.0001: input,hidraw0: USB HID
v1.11 Mouse [Lenovo Optical USB Mouse] on usb-0000:03:00.0-1/input0
[ 5.670722] bus: 'usb': add driver btusb
[ 5.670736] bus: 'usb': driver_probe_device: matched device 1-1.5:1.0
with driver btusb
[ 5.670739] bus: 'usb': really_probe: probing driver btusb with
device 1-1.5:1.0
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux 3.13-rc1 is out
2013-11-23 0:43 ` Matthew Garrett
@ 2013-11-23 1:08 ` Linus Torvalds
0 siblings, 0 replies; 7+ messages in thread
From: Linus Torvalds @ 2013-11-23 1:08 UTC (permalink / raw)
To: Matthew Garrett; +Cc: Linux Kernel Mailing List
On Fri, Nov 22, 2013 at 4:43 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> I'd sent a pull yesterday (http://lkml.org/lkml/2013/11/21/599 ) which
> may have missed your cutoff, but it seems worth checking.
No, it didn't miss my cutoff, and it wasn't even eaten by the gmail
spam filters, but it *had* missed my normal pattern for checking that
I had merged all git pull requests, which is why I had overlooked it.
Pulled now (going through the allmodconfig build test before being
pushed out shortly).
Btw, the reason it missed my normal check is that I search for
"in:inbox git pull" as a sanity check that I don't have anything
pending. Now, *most* of the time I tend to catch things regardless
just by virtue of reading email carefully, but when I'm busy it
definitely helps if your email matches that pattern.
The easiest (and most common) way to do that is to have the subject
line be something like
[GIT PULL] sound fixes #2 for 3.13-rc1
but there are other patterns. For example, David Miller tends to have
instead a subject line like
[GIT] Networking
and then "Please pull" in the body of the email. So the "in:inbox git
pull" thing basically catches pretty much everybody.
Except for you...
You use David Miller's subject line, but you don't have the "please
pull" part, so your email missed my "did I pull everything that I had
pending" check.
For very similar reasons, for people sending me a patch, it really
*really* helps if there's a "[patch]" (possibly with a n/m number
pattern) in the subject line.. Or make sure you send me a git diff,
because I also tend to search for the string "diff --git". Of course,
the main person who sends me patches is Andrew Morton, so I mostly
just search for "from:akpm" :)
Linus
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux 3.13-rc1 is out
2013-11-23 0:51 ` James Cloos
@ 2013-11-23 2:32 ` Jongman Heo
0 siblings, 0 replies; 7+ messages in thread
From: Jongman Heo @ 2013-11-23 2:32 UTC (permalink / raw)
To: linux-kernel
James Cloos <cloos <at> jhcloos.com> writes:
>
> This combination:
>
> # CONFIG_SYSTEM_TRUSTED_KEYRING is not set
> CONFIG_TRUSTED_KEYS=m
>
> (acquired by oldconfig and N to system keyring)
>
> fails with:
>
> Pass 2
> CC [M] crypto/asymmetric_keys/x509_rsakey-asn1.o
> CC [M] crypto/asymmetric_keys/x509_cert_parser.o
> CC [M] crypto/asymmetric_keys/x509_public_key.o
> crypto/asymmetric_keys/x509_public_key.c: In
function ‘x509_key_preparse’:
> crypto/asymmetric_keys/x509_public_key.c:237:35:
error: ‘system_trusted_keyring’
> undeclared (first use in this function)
> ret = x509_validate_trust(cert, system_trusted_keyring);
> ^
> crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared
identifier is reported
> only once for each function it appears in
> make[2]: *** [crypto/asymmetric_keys/x509_public_key.o] Error 1
> make[1]: *** [crypto/asymmetric_keys] Error 2
> make: *** [crypto] Error 2
>
> Perhaps include/keys/system_keyring.h should have a definition for
> system_trusted_keyring in the #ifndef CONFIG_SYSTEM_TRUSTED_KEYRING
> case (which may entail just removing the #ifdef).
>
> Commits b56e5a17b6b9acd1 and 09fbc47373826d67 are relevant.
>
> -JimC
I have same problem too.
Using following band-aid patch (though I'm not sure it's correct), build
is ok;
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -67,6 +67,7 @@ int integrity_digsig_verify(const unsigned int id, const
char *sig, int siglen,
return -EOPNOTSUPP;
}
+#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
int integrity_init_keyring(const unsigned int id)
{
const struct cred *cred = current_cred();
@@ -84,3 +85,4 @@ int integrity_init_keyring(const unsigned int id)
keyring_name[id], PTR_ERR(keyring[id]));
return 0;
}
+#endif
But, I encounter another build issue;
CC crypto/asymmetric_keys/x509_public_key.o
crypto/asymmetric_keys/x509_public_key.c: In function
‘x509_key_preparse’:
crypto/asymmetric_keys/x509_public_key.c:237:35: error:
‘system_trusted_keyring’ undeclared (first use in this function)
ret = x509_validate_trust(cert, system_trusted_keyring);
^
crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared
identifier is reported only once for each function it appears in
make[2]: *** [crypto/asymmetric_keys/x509_public_key.o] Error 1
make[1]: *** [crypto/asymmetric_keys] Error 2
make: *** [crypto] Error 2
Looks like it's caused by following combination...
# CONFIG_SYSTEM_TRUSTED_KEYRING is not set
CONFIG_X509_CERTIFICATE_PARSER=y
Jongman Heo
^ permalink raw reply [flat|nested] 7+ messages in thread
* linux-next stats (Was: Linux 3.13-rc1 is out)
2013-11-22 20:36 Linux 3.13-rc1 is out Linus Torvalds
` (2 preceding siblings ...)
2013-11-23 0:58 ` Shuah Khan
@ 2013-11-25 0:10 ` Stephen Rothwell
3 siblings, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2013-11-25 0:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, linux-next
[-- Attachment #1: Type: text/plain, Size: 4444 bytes --]
On Fri, 22 Nov 2013 12:36:37 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> Talking about mistakes... I suspect it was a mistake to have that
> extra week before the merge window opened, and I probably should just
> have done a 3.12-rc8 instead. Because the linux-next statistics look
> suspicious, and we had extra stuff show up there not just in that
> first week. Clearly people took that "let's have an extra week of
> merge window" and extrapolated it a bit too much. Oh, well. Live and
> learn.
As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)
(No merge commits counted, next-20131105 was the linux-next based on v3.12)
Commits in v3.13-rc1 (relative to v3.12): 10518 (v3.12-rc11: 9474)
Commits in next-20131105: 9029 (next-20130903: 8891)
Commits with the same SHA1: 7979 ( 7991)
Commits with the same patch_id: 621 (1) ( 472)
Commits with the same subject line: 70 (1) ( 70)
(1) not counting those in the lines above.
So commits in -rc1 that were in next-20131105: 8670 82.4% (8533 90.1%)
Commits in -rc1 that were not in next-20131105: 1848 17.6% ( 941 9.9%)
So worse than last time, probably because of the 1 week delay.
[Aside: if I use next-20131111 as a base (when Linus' starting doing
merges in earnest), the stats look like this:
Commits in next-20131111: 9906
Commits with the same SHA1: 9156
Commits with the same patch_id: 354 (1)
Commits with the same subject line: 41 (1)
So commits in -rc1 that were in next-20131111: 9551 90.8%
Commits in -rc1 that were not in next-20131105: 967 9.2%
So, much more in line with previous releases.
]
Some breakdown of the list of extra commits (relative to next-20131105)
in -rc1:
Top ten first word of commit summary:
337 drm
115 btrfs
83 perf
68 alsa
50 asoc
49 arm
46 net
31 powerpc
27 netfilter
27 acpi
Top ten authors:
66 Ben Skeggs <bskeggs@redhat.com>
63 Takashi Iwai <tiwai@suse.de>
63 Al Viro <viro@zeniv.linux.org.uk>
46 Alex Deucher <alexander.deucher@amd.com>
39 Ben Widawsky <benjamin.widawsky@intel.com>
33 Josef Bacik <jbacik@fusionio.com>
31 Johannes Berg <johannes.berg@intel.com>
29 J. Bruce Fields <bfields@redhat.com>
29 Dan Carpenter <dan.carpenter@oracle.com>
27 Peter Zijlstra <peterz@infradead.org>
Top ten commiters:
195 David S. Miller <davem@davemloft.net>
117 Chris Mason <chris.mason@fusionio.com>
95 Daniel Vetter <daniel.vetter@ffwll.ch>
94 Al Viro <viro@zeniv.linux.org.uk>
86 Ben Skeggs <bskeggs@redhat.com>
82 Arnaldo Carvalho de Melo <acme@redhat.com>
74 Alex Deucher <alexander.deucher@amd.com>
69 Takashi Iwai <tiwai@suse.de>
53 Dave Airlie <airlied@redhat.com>
52 Mark Brown <broonie@linaro.org>
There are also 358 commits in next-20131105 that didn't make it into
v3.13-rc1.
Top ten first word of commit summary:
51 arm
40 crypto
21 block
11 x86
11 ocfs2
11 dm
10 ceph
10 bluetooth
9 iov_iter
9 9p
Top ten authors:
27 Kent Overstreet <kmo@daterainc.com>
22 Dave Kleikamp <dave.kleikamp@oracle.com>
19 Andrew Morton <akpm@linux-foundation.org>
9 Zach Brown <zab@zabbo.net>
9 Denis Carikli <denis@eukrea.com>
8 Geyslan G. Bem <geyslan@gmail.com>
7 Sachin Kamat <sachin.kamat@linaro.org>
7 Kees Cook <keescook@chromium.org>
7 Alex Porosanu <alexandru.porosanu@freescale.com>
6 Yan, Zheng <zheng.z.yan@intel.com>
Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).
Top ten commiters:
93 Stephen Rothwell <sfr@canb.auug.org.au>
48 Herbert Xu <herbert@gondor.apana.org.au>
33 Dave Kleikamp <dave.kleikamp@oracle.com>
30 Jens Axboe <axboe@kernel.dk>
27 Shawn Guo <shawn.guo@linaro.org>
17 Kukjin Kim <kgene.kim@samsung.com>
11 Mauro Carvalho Chehab <m.chehab@samsung.com>
10 Jason Wessel <jason.wessel@windriver.com>
9 Sage Weil <sage@inktank.com>
9 Eric Van Hensbergen <ericvh@gmail.com>
Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-11-25 0:10 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-22 20:36 Linux 3.13-rc1 is out Linus Torvalds
2013-11-23 0:43 ` Matthew Garrett
2013-11-23 1:08 ` Linus Torvalds
2013-11-23 0:51 ` James Cloos
2013-11-23 2:32 ` Jongman Heo
2013-11-23 0:58 ` Shuah Khan
2013-11-25 0:10 ` linux-next stats (Was: Linux 3.13-rc1 is out) Stephen Rothwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).