* Linux 4.11-rc1
@ 2017-03-05 21:41 Linus Torvalds
2017-03-05 23:52 ` linux-next: stats (Was: Linux 4.11-rc1) Stephen Rothwell
0 siblings, 1 reply; 3+ messages in thread
From: Linus Torvalds @ 2017-03-05 21:41 UTC (permalink / raw)
To: Linux Kernel Mailing List
So two weeks have passed, the merge window is over, and 4.11-rc1 has
been tagged and pushed out.
This looks like a fairly regular release. It's on the smallish side,
but mainly just compared to 4.9 and 4.10 - so it's not really
_unusually_ small (in recent kernels, 4.1, 4.3, 4.5, 4.7 and now 4.11
all had about the same number of commits in the merge window).
It _does_ feel like there was more stuff that I was asked to pull than
was in linux-next. That always happens, but seems to have happened
more now than usually. Comparing to the linux-next tree at the time of
the 4.10 release, almost 18% of the non-merge commits were not in
Linux-next. That seems higher than usual, although I guess Stephen
Rothwell has actual numbers from past merges.
Now, about a quarter of the patches that weren't in linux-next do end
up having the same patch ID as something that was, so some of it was
due to just rebasing. But still - we have about 13% of the merge
window that wasn't in linux-next when 4.10 was released.
Looking at the sources of that, there's a few different classes:
- fixes.
This is obviously ok and inevitable. I don't expect everything to
have been in linux-next, after all.
- the statx() systen call thing.
Yeah, I'll allow this one too, because quite frankly, the first
version of that patch was posted over six years ago.
- there's the quite noticeable <linux/sched.h> split-up series
This one was posted and discussed before the merge window, and
needed to be merged late (and even then caused some conflicts). So it
had real reasons for late inclusion.
- a couple of subsystems. drm, Infiniband, watchdog and btrfs stand out.
That last case is what I found rather annoying this merge window.
In particular, if you cannot follow the simple merge window rules
(this whole two-week merge window and linux-next process has been in
place over a decade), at least make the end result look good. Make it
all look easy and problem-free. Make it look like you know what you're
doing, and make damn sure the code was tested exhaustively some other
way.
Because if you bypass the linux-next sanity checks, you had better
have your own sanity checks that you replaced them with. Or you just
need to be _so_ good that nobody minds you bypassing them, and nobody
ever notices your shortcuts.
Saying "screw all the rules and processes we have in place to verify
things", and then sending me crap that doesn't even build for me is
_not_ acceptable.
You people know who you are. Next merge window I will not accept
anything even remotely like that. Things that haven't been in
linux-next will be rejected, and since you're already on my shit-list
you'll get shouted at again.
Linus
---
Al Viro (4):
vfs sendmsg updates
vfs pile two
vfs 'statx()' update
misc final vfs updates
Alex Williamson (1):
VFIO updates
Alexandre Belloni (1):
RTC updates
Andrew Morton (3):
updates
more updates
yet more updates
Anna Schumaker (1):
NFS client updates
Arnd Bergmann (8):
ARM SoC non-urgent fixes
ARM SoC platform updates
ARM SoC 64-bit updates
ARM SoC defconfig updates
ARM DT updates
ARM 64-bit DT updates
ARM SoC driver updates
ARM SoC late DT updates
Bartlomiej Zolnierkiewicz (1):
fbdev updates
Bjorn Andersson (2):
remoteproc updates
rpmsg updates
Bjorn Helgaas (2):
PCI updates
PCI fixes
Bob Peterson (1):
GFS2 fix
Borislav Petkov (1):
EDAC updates
Brian Norris (1):
MTD updates
Bruce Fields (1):
nfsd updates
Chris Mason (2):
btrfs updates
more btrfs updates
Corey Minyard (1):
IPMI updates
Dan Williams (1):
libnvdimm fixes
Darren Hart (1):
x86 platform driver updates
Darrick Wong (1):
xfs updates
Dave Airlie (3):
drm updates
drm fixes
drm AST2500 support
David Miller (6):
networking updates
networking fixes
sparc updates
networking fixes
IDE updates
networking fixes
Dmitry Torokhov (1):
input updates
Doug Ledford (3):
rdma updates
Mellanox rdma updates
rdma DMA mapping updates
Eric Biederman (1):
namespace updates
Geert Uytterhoeven (1):
m68k updates
Greg KH (6):
USB/PHY updates
char/misc driver updates
driver core updates
staging/iio driver updates
tty/serial driver updates
staging/IIO driver fixes
Greg Ungerer (1):
m68nommu update
Guenter Roeck (3):
hwmon updates
watchdog updates
more watchdog updates
Helge Deller (1):
parisc fixes and cleanups
Herbert Xu (2):
crypto update
crypto fixes
Ilya Dryomov (1):
ceph updates
Ingo Molnar (23):
debugobjects updates
RCU updates
EFI updates
perf updates
RAS updates
scheduler updates
locking updates
x86 apic changes
x86 asm update
x86 boot updates
x86 cleanups
x86 cpufeature updates
x86 fpu updates
x86 microcode updates
x86 mm updates
x86 platform updates
objtool fixes
locking fixes
perf fixes
scheduler fixes
x86 fixes
objtool relocation fixes
sched.h split-up
Jacek Anaszewski (1):
LED updates
Jaegeuk Kim (1):
f2fs updates
James Bottomley (2):
SCSI updates
more SCSI updates
James Hogan (1):
MIPS updates
James Morris (3):
security layer updates
seccomp fix
security subsystem fixes
Jan Kara (1):
UDF fixes and cleanups
Jens Axboe (3):
block layer updates
block updates and fixes
block layer fixes
Jessica Yu (1):
modules updates
Jiri Kosina (3):
livepatching updates
HID updates
HID fix
Joerg Roedel (3):
IOMMU UPDATES
IOMMU fix
IOMMU fixes
Jonathan Corbet (2):
documentation updates
documentation fixes
Juergen Gross (1):
xen updates
Kees Cook (5):
pstore updates
usercopy test updates
rodata updates
gcc-plugins updates
usercopy test fix
Lee Jones (2):
MFD updates
backlight updates
Linus Walleij (2):
pin control updates
GPIO updates
Mark Brown (3):
regmap updates
regulator updates
spi updates
Martin Schwidefsky (2):
s390 updates
more s390 updates
Matthew Wilcox (1):
IDR rewrite
Mauro Carvalho Chehab (1):
media updates
Max Filippov (1):
Xtensa updates
Michael Ellerman (2):
powerpc updates
more powerpc updates
Michael Tsirkin (1):
vhost updates
Mike Marshall (1):
orangefs updates
Mike Snitzer (2):
device mapper updates
device mapper fixes
Miklos Szeredi (2):
overlayfs updates
fuse update
Nicholas Bellinger (1):
SCSI target updates
Paolo Bonzini (1):
KVM updates
Paul Gortmaker (1):
exception table module split
Paul Moore (1):
audit updates
Petr Mladek (1):
printk updates
Radim Krčmář (1):
more KVM updates
Rafael Wysocki (5):
device property updates
power management updates
ACPI updates
ACPI fix
turbostat utility updates
Rob Herring (1):
DeviceTree updates
Robert Peterson (1):
GFS2 updates
Russell King (1):
ARM updates
Sebastian Reichel (1):
power supply and reset updates
Shaohua Li (1):
md updates
Shuah Khan (2):
Kselftest update
kselftest fix
Stafford Horne (1):
OpenRISC updates
Stephen Boyd (1):
clk updates
Steve French (2):
CIFS/SMB3 updates
SMB3 fixes
Steven Rostedt (3):
tracing updates
another tracing update
ktest updates
Takashi Iwai (2):
sound updates
sound fixes
Ted Ts'o (2):
fscrypt updates
ext4 updates
Tejun Heo (4):
libata updates
percpu update
cgroup updates
workqueue update
Thierry Reding (1):
pwm updates
Thomas Gleixner (2):
timer updates
irq updates
Ulf Hansson (1):
MMC updates
Vineet Gupta (1):
ARC updates
Vinod Koul (1):
dmaengine updates
Will Deacon (2):
arm64 updates
arm64 fixes
Wolfram Sang (1):
i2c updates
Zhang Rui (1):
thermal management updates
^ permalink raw reply [flat|nested] 3+ messages in thread
* linux-next: stats (Was: Linux 4.11-rc1)
2017-03-05 21:41 Linux 4.11-rc1 Linus Torvalds
@ 2017-03-05 23:52 ` Stephen Rothwell
2017-03-06 19:10 ` David Sterba
0 siblings, 1 reply; 3+ messages in thread
From: Stephen Rothwell @ 2017-03-05 23:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
Hi Linus,
On Sun, 5 Mar 2017 13:41:04 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> It _does_ feel like there was more stuff that I was asked to pull than
> was in linux-next. That always happens, but seems to have happened
> more now than usually. Comparing to the linux-next tree at the time of
> the 4.10 release, almost 18% of the non-merge commits were not in
> Linux-next. That seems higher than usual, although I guess Stephen
> Rothwell has actual numbers from past merges.
>
> Now, about a quarter of the patches that weren't in linux-next do end
> up having the same patch ID as something that was, so some of it was
> due to just rebasing. But still - we have about 13% of the merge
> window that wasn't in linux-next when 4.10 was released.
>
> Looking at the sources of that, there's a few different classes:
>
> - fixes.
>
> This is obviously ok and inevitable. I don't expect everything to
> have been in linux-next, after all.
>
> - the statx() systen call thing.
>
> Yeah, I'll allow this one too, because quite frankly, the first
> version of that patch was posted over six years ago.
>
> - there's the quite noticeable <linux/sched.h> split-up series
>
> This one was posted and discussed before the merge window, and
> needed to be merged late (and even then caused some conflicts). So it
> had real reasons for late inclusion.
>
> - a couple of subsystems. drm, Infiniband, watchdog and btrfs stand out.
My stats:
As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)
(No merge commits counted, next-20170220 was the first linux-next after
the merge window opened.)
Commits in v4.11-rc1 (relative to v4.10): 10960
Commits in next-20170220: 9791
Commits with the same SHA1: 9016
Commits with the same patch_id: 479 (1)
Commits with the same subject line: 68 (1)
(1) not counting those in the lines above.
So commits in -rc1 that were in next-20170220: 9563 87%
[
v4.10-rc1 like this:
Commits in v4.10-rc1 (relative to v4.9): 11455
Commits in next-20161212: 10625
Commits with the same SHA1: 9927
Commits with the same patch_id: 437 (1)
Commits with the same subject line: 25 (1)
(1) not counting those in the lines above.
So commits in -rc1 that were in next-20161212: 10389 90%
And v4.9-rc1 like this:
Commits in v4.9-rc1 (relative to v4.8): 14308
Commits in next-20161004: 13539
Commits with the same SHA1: 12716
Commits with the same patch_id: 485 (1)
Commits with the same subject line: 33 (1)
(1) not counting those in the lines above.
So commits in -rc1 that were in next-20161004: 13234 92%
So this time we have slightly more rebasing and overall more "extra" commits.
]
Some breakdown of the list of extra commits (relative to next-20170220)
in -rc1:
Top ten first word of commit summary:
142 sched
117 drm
72 net
66 ib
63 watchdog
61 btrfs
60 scsi
48 f2fs
43 tools
29 perf
Top ten authors:
146 mingo@kernel.org
46 bskeggs@redhat.com
45 len.brown@intel.com
39 bart.vanassche@sandisk.com
32 linux@roeck-us.net
32 acourbot@nvidia.com
28 nborisov@suse.com
26 idryomov@gmail.com
22 hch@lst.de
21 anna.schumaker@netapp.com
Top ten commiters:
217 davem@davemloft.net
161 mingo@kernel.org
88 bskeggs@redhat.com
79 dledford@redhat.com
64 linux@roeck-us.net
63 anna.schumaker@netapp.com
59 martin.petersen@oracle.com
58 dsterba@suse.com
57 axboe@fb.com
52 idryomov@gmail.com
There are also 229 commits in next-20170220 that didn't make it into
v4.11-rc1.
Top ten first word of commit summary:
19 mm
18 arm
12 edac
9 keys
9 befs
7 random
6 target
6 coresight
6 bf609
5 edac.txt
Top ten authors:
19 mchehab@kernel.org
17 akpm@linux-foundation.org
11 dhowells@redhat.com
10 olof@lixom.net
9 luisbg@osg.samsung.com
8 viro@zeniv.linux.org.uk
7 arnd@arndb.de
6 varun@chelsio.com
5 sonic.zhang@analog.com
4 realmz6@gmail.com
Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).
Top ten commiters:
76 sfr@canb.auug.org.au
20 mchehab@kernel.org
16 steven@ubuntu-virtualbox.(none)
11 dhowells@redhat.com
10 olof@lixom.net
9 luisbg@osg.samsung.com
8 viro@zeniv.linux.org.uk
7 tytso@mit.edu
7 bart.vanassche@sandisk.com
6 mathieu.poirier@linaro.org
Those commits by me are from the quilt series (mainly Andrew's mmotm
tree). The steven@ubuntu-virtualbox.(none) ones are form a very out of
date blackfin tree that has now been removed from linux-next.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: linux-next: stats (Was: Linux 4.11-rc1)
2017-03-05 23:52 ` linux-next: stats (Was: Linux 4.11-rc1) Stephen Rothwell
@ 2017-03-06 19:10 ` David Sterba
0 siblings, 0 replies; 3+ messages in thread
From: David Sterba @ 2017-03-06 19:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linus Torvalds, Linux Kernel Mailing List
Hi,
On Mon, Mar 06, 2017 at 10:52:00AM +1100, Stephen Rothwell wrote:
> > - a couple of subsystems. drm, Infiniband, watchdog and btrfs stand out.
> Top ten first word of commit summary:
...
> 61 btrfs
I can comment on the btrfs part. We have lots of cleanups for 4.11 and
good part of all the patches are changing function parameters, one per
patch. Therefore the overall counts are high.
The first batch has been in for-next since mid Jan, and the second one
was added right after to the beginning of the merge window (20170221).
All series merged had appeared on the mailinglist a few days before 4.10
release but had to be updated due to some fixes regarding whitespace and
over-80-char lines.
So strictly speaking the patches did come late, but there was very low
risk of breakage. Getting all the queued cleanups out is a relief as
they tend to cause merge conflicts with pending patchsets.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-03-06 19:12 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-05 21:41 Linux 4.11-rc1 Linus Torvalds
2017-03-05 23:52 ` linux-next: stats (Was: Linux 4.11-rc1) Stephen Rothwell
2017-03-06 19:10 ` David Sterba
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.