From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933967AbcLHAEb (ORCPT ); Wed, 7 Dec 2016 19:04:31 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:60662 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932400AbcLHAEa (ORCPT ); Wed, 7 Dec 2016 19:04:30 -0500 Date: Thu, 8 Dec 2016 00:04:29 +0000 From: Al Viro To: Linus Torvalds Cc: Linux Kernel Mailing List Subject: Re: Note on 4.10 merge window timing (was Re: Linux 4.9-rc8) Message-ID: <20161208000428.GV1555@ZenIV.linux.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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:]]*' sed -i -e "s!$PATT!#include !" \ `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.