linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Linux 4.20-rc1
Date: Sun, 4 Nov 2018 16:12:45 -0800	[thread overview]
Message-ID: <CAHk-=whDiwASMgw8Q7TNA2MJhf3s=ouK4+_3ioqmobs-yagnkQ@mail.gmail.com> (raw)

So I did debate calling it 5.0, but if we all help each other, I'm
sure we can count to 20. It's a nice round number, and I didn't want
to make a pattern of it. I think 5.0 happens next year, because then I
*really* run out of fingers and toes.

Anyway, 4.20-rc1 is tagged and pushed out, and the merge window is
over. This was a fairly big merge window, but it didn't break any
records, just solid. And things look pretty regular, with about 70% of
the patch is driver updates (gpu drivers are looming large as usual,
but there's changes all over). The rest is arch updates (x86, arm64,
arm, powerpc and the new C-SKY architecture), header files,
networking, core mm and kernel, and tooling.

In fact, tooling is quite noticeable. A fair amount of selftest
changes, but also various perf tooling updates.

There's a vfs pull request I declined and it might still go in later
in a slightly reduced form, but apart from that I think everything got
merged. We had one pull request that almost missed the merge windows
due to a silly change in my email setup, but I verified that nothing
else had happened to hit that special case.

One thing I _would_ like to point out as the merge window closes: I
tend to delay some pull requests that I want to take a closer look at
until the second week of the merge window when things are calming
down, and that _really_ means that I'd like to get all the normal pull
requests in the first week of the two-week merge window. And most
people really followed that, but by Wednesday this week I had gotten a
big frustrated that I kept getting new pull requests when I wanted to
really just spend most of the day looking through the ones that
deserved a bit of extra attention.

And yes, people generally kind of know about this and I really do get
*most* pull requests early. But I'm considering trying to make that a
more explicit rule that I will literally stop taking new pull requests
some time during the second week unless you have a good reason for why
it was delayed.

Because yes, the merge window is two weeks, but it's two weeks partly
exactly _because_ people (not just me) sometimes need extra time to
resolve any possible issues, not because regular everyday pull
requests should spread out over the whole two weeks. The development
for things meant for the next release should have been done by the
time the merge window opens.

Anyway, let's see. Maybe it won't be needed. It hasn't become a
problem, it just was starting to feel a bit tight there.

Oh, and I did try to do the reply emails. And I'm _entirely_ sure that
I must have missed acknowledging emails for a few pull requests. I'm
hoping that by the time the next merge window rolls around, we'll just
have new automation for it, so that everybody just automatically gets
notified when their pull request hit mainline. In the meantime, you
have a good chance - but not a guarantee - that I'll send a "Pulled"
ack email when I start processing a pull request.

And as usual for rc1, the log below is just the list of people I
pulled from with a one-liner "mergelog". Very much a high-level
summary of merges, for details you need to look into the git tree..

                    Linus

---
Al Viro (8):
    tty ioctl updates
    vfs fixes
    compat_ioctl fixes
    alpha syscall glue updates
    more ->lookup() cleanups
    AFS updates
    misc vfs updates
    9p fix

Alex Williamson (1):
    VFIO updates

Alexandre Belloni (1):
    RTC updates

Andrew Morton (3):
    updates
    more updates
    more updates

Arnd Bergmann (4):
    ARM SoC device tree updates
    ARM SoC defconfig updates
    ARM SoC driver updates
    ARM SoC platform updates

Bartlomiej Zolnierkiewicz (1):
    fbdev updates

Benson Leung (1):
    chrome-platform updates

Bjorn Andersson (2):
    remoteproc updates
    rpmsg updates

Bjorn Helgaas (1):
    PCI updates

Bob Peterson (1):
    gfs2 updates

Boris Brezillon (1):
    mtd updates

Borislav Petkov (2):
    EDAC updates
    more EDAC updates

Bruce Fields (1):
    nfsd updates

Catalin Marinas (2):
    arm64 updates
    more arm64 updates

Christoph Hellwig (3):
    dma mapping updates
    more dma-mapping updates
    dma-mapping fix

Corey Minyard (1):
    IPMI updates

Dan Williams (1):
    libnvdimm updates

Darren Hart (1):
    x86 platform driver updates

Dave Airlie (2):
    drm updates
    drm fixes

Dave Chinner (1):
    vfs dedup fixes

David Kleikamp (1):
    jfs updates

David Miller (8):
    sparc updates
    networking updates
    sparc fix
    sparc fixes
    networking fixes
    networking fixes
    sparc fixes
    networking fixes

David Sterba (2):
    btrfs updates
    more btrfs updates

Dennis Zhou (1):
    percpu fixes

Dmitry Torokhov (1):
    input updates

Dominik Brodowski (1):
    pcmcia fixes

Dominique Martinet (1):
    9p updates

Eduardo Valentin (1):
    thermal SoC updates

Eric Biederman (1):
    siginfo updates

Geert Uytterhoeven (1):
    m68k updates

Greg KH (5):
    USB/PHY updates
    driver core updates
    char/misc driver updates
    staging/IIO driver updates
    tty/serial updates

Greg Ungerer (1):
    m68k nommu fix

Guenter Roeck (1):
    hwmon updates

Guo Ren (2):
    C-SKY architecture port
    csky dtb fixups

Helge Deller (2):
    parisc updates
    parisc updates

Herbert Xu (1):
    crypto updates

Ilya Dryomov (1):
    ceph updates

Ingo Molnar (22):
    RCU updates
    EFI updates
    locking and misc x86 updates
    perf updates
    RAS updates
    scheduler updates
    x86 apic updates
    x86 asm updates
    x86 boot updates
    x86 build update
    x86 cpu updates
    x86 grub2 updates
    x86 hyperv updates
    x86 mm updates
    x86 paravirt updates
    x86 platform updates
    x86 pti updates
    x86 vdso updates
    irq fixes
    perf updates and fixes
    x86 fixes
    scheduler fixes

Jacek Anaszewski (2):
    LED updates
    LED fix

Jaegeuk Kim (1):
    f2fs updates

James Bottomley (2):
    SCSI updates
    more SCSI updates

James Morris (6):
    security subsystem updates
    integrity updates
    TPM updates
    smack updates
    LoadPin updates
    keys updates

Jan Kara (2):
    fsnotify updates
    ext2 and udf updates

Jason Gunthorpe (1):
    rdma updates

Jassi Brar (1):
    mailbox updates

Jens Axboe (4):
    block layer updates
    libata updates
    more block layer updates
    block layer fixes

Jiri Kosina (1):
    HID updates

Joerg Roedel (1):
    IOMMU updates

John Johansen (1):
    apparmor updates

Jon Mason (1):
    NTB updates

Jonathan Corbet (1):
    documentation updates

Juergen Gross (1):
    xen fixes

Kees Cook (3):
    pstore updates
    VLA removal
    stackleak gcc plugin

Konrad Rzeszutek Wilk (1):
    xen swiotlb fix

Lee Jones (2):
    MFD updates
    backlight updates

Linus Walleij (2):
    pin control updates
    GPIO updates

Mark Brown (3):
    regmap updates
    spi updates
    regulator updates

Mark Salter (1):
    c6x update

Martin Schwidefsky (1):
    s390 updates

Masahiro Yamada (2):
    Kbuild updates
    Kbuild updates

Matthew Wilcox (1):
    XArray conversion

Mauro Carvalho Chehab (2):
    media updates
    new experimental media request API

Max Filippov (1):
    Xtensa fixes and cleanups

Michael Ellerman (2):
    powerpc updates
    powerpc fixes

Michael Tsirkin (1):
    virtio/vhost updates

Miguel Ojeda (1):
    compiler attribute updates

Mike Marshall (1):
    orangefs updates

Mike Snitzer (1):
    device mapper updates

Miklos Szeredi (2):
    fuse updates
    overlayfs updates

Nicolas Pitre (1):
    cramfs fixes

Olof Johansson (1):
    ARM SoC fixes

Palmer Dabbelt (3):
    RISC-V updates
    more RISC-V updates
    RISC-V defconfig update

Paul Burton (2):
    MIPS fixes
    MIPS updates

Paul Moore (1):
    SELinux updates

Petr Mladek (1):
    printk updates

Radim Krčmář (1):
    KVM updates

Rafael Wysocki (4):
    power management updates
    ACPI updates
    more power management updates
    more ACPI updates

Richard Weinberger (2):
    UML updates
    UBIFS updates

Rob Herring (2):
    Devicetree updates
    Devicetree fixes

Russell King (1):
    ARM updates

Sebastian Reichel (1):
    power supply and reset updates

Shaohua Li (1):
    md updates

Shuah Khan (1):
    kselftest updates

Stephen Boyd (1):
    clk updates

Steve French (2):
    cifs updates
    cifs fixes and updates

Steven Rostedt (2):
    tracing fixes
    tracing updates

Takashi Iwai (2):
    sound updates
    sound fixes

Ted Ts'o (1):
    ext4 updates

Tejun Heo (1):
    cgroup updates

Thierry Reding (1):
    pwm updates

Thomas Gleixner (3):
    timekeeping updates
    irq updates
    more timer updates

Tony Luck (1):
    ia64 updates

Trond Myklebust (2):
    NFS client updates
    NFS client bugfixes

Ulf Hansson (1):
    MMC updates

Vinod Koul (1):
    dmaengine updates

Wim Van Sebroeck (1):
    watchdog updates

Wolfram Sang (2):
    i2c updates
    i2c fixes

Zhang Rui (1):
    thermal management updates

             reply	other threads:[~2018-11-05  0:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-05  0:12 Linus Torvalds [this message]
2018-11-05 10:25 ` System not booting since dm changes? (was Linux 4.20-rc1) Michael Ellerman
2018-11-05 13:51   ` Mike Snitzer
2018-11-05 14:35     ` Satheesh Rajendran
2018-11-05 15:08       ` Jens Axboe
2018-11-07  0:59     ` Michael Ellerman
2018-11-06 23:04 ` Linux 4.20-rc1 Darren Hart
2018-11-08  4:40 ` linux-next: stats (Was: Linux 4.20-rc1) Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=whDiwASMgw8Q7TNA2MJhf3s=ouK4+_3ioqmobs-yagnkQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).