From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [git pull] vfs part 3 Date: Fri, 17 Apr 2015 16:50:17 +0100 Message-ID: <20150417155017.GB889@ZenIV.linux.org.uk> References: <20150416010437.GV889@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Linux Kernel Mailing List , linux-fsdevel To: Linus Torvalds Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Apr 16, 2015 at 11:26:48PM -0400, Linus Torvalds wrote: > On Wed, Apr 15, 2015 at 9:04 PM, Al Viro wrote: > > > > That leaves only the actual d_inode annotations series out of the > > stuff already in for-next; there are several piles of stuff from various > > folks I'm going to add there tonight, leave it all to stew until the middle > > of the next week or so and send the final pull request then. I hoped to do > > that last bit on Monday, but since there won't be -next on Thursday and > > Friday, this will probably have to happen a couple of days later ;-/ > > We can just leave that for next time. > > I abhor this "feed things in chunks _during_ the merge window". > > If this had been four different and separate branches that did > separate cleanups and had all been independently of each other in > linux-next since before the merge window, and had been in a "ready to > merge" state, that would be one thing. But this kind of "let's feed > Linus one chunk, then work on the next one" is not how it is supposed > to work. Not during the merge window, Actually, the pull requests so far (as well as d_inode annotation patches) had been in -next - the main reason for not sending a single pull request was the fact that such single pull would bring in a large part of net-next. Separation between #2 and #3 wasn't due to "work on the next one" kind of thing either - both had been there at the same time... How do you prefer to deal with the situations like one with net-next? I really don't know - mostly I've managed to avoid that kind of merges from other trees, so it hadn't come up. This time the topology inside vfs.git#for-next had ended up much trickier than usual... And do you have problems with actual d_inode/d_backing_inode annotation patches left in for-next?