linux-kernel - Re: Note on 4.10 merge window timing (was Re: Linux 4.9-rc8)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161208000428.GV1555@ZenIV.linux.org.uk>
Date:   Thu, 8 Dec 2016 00:04:29 +0000
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Note on 4.10 merge window timing (was Re: Linux 4.9-rc8)

On Wed, Dec 07, 2016 at 10:32:47AM -0800, Linus Torvalds wrote:

> Btw, for anybody with a calendar (or just excellent finger counting
> skills), this should all be obvious, but I thought I'd make it very
> explicit anyway: this means that 4.9 will be released this upcoming
> Sunday, December 11th. Unless something really bad happens.
> 
> Now, for people counting along, that would mean that the merge window
> for 4.10 ends two weeks later, on December 25.
> 
> That date may look familiar. It's Christmas Day. If you're originally
> from Finland like me, it's the day when you relax after the real
> celebrations, which would be on Christmas Eve.
> 
> What does this all mean? It means that I might be doing the actual rc1
> release on the 25th, but I'm sure as hell not going to do any real
> work that day, or even the day before. So realistically, this is going
> to be a truncated merge window, and if you don't send in your pull
> requests in a timely manner, they are going to be dropped on the
> floor.

Could you run this just before cutting 4.10-rc1?

PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*<asm/uaccess.h>'
sed -i -e "s!$PATT!#include <linux/uaccess.h>!" \
	`git grep -l "$PATT"|grep -v ^include/linux/uaccess.h`

Doing that against 4.9 would only cause a bunch of pointless trivial
conflicts during the merge window and would probably need to be run
again to pick the newly added includes of asm/uaccess.h after the end
of the window anyway.  It's 100% mechanical search-and-replace - the only
remaining include of asm/uaccess.h should be in linux/uaccess.h and
everything else should switch to asm/uaccess.h.  There used to be several
places where linux/uaccess.h would cause trouble (the worst was probably
asm/processor.h on x86), but all of those had been taken out and shot during
the last window and AFAICS nothing new of that sort has appeared in anything
merged into -next.