On Thu, Apr 16, 2015 at 11:26:48PM -0400, Linus Torvalds wrote: > On Wed, Apr 15, 2015 at 9:04 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
