All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.