Messages in this thread | | | Date | Fri, 17 Apr 2015 16:50:17 +0100 | From | Al Viro <> | Subject | Re: [git pull] vfs part 3 |
| |
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@zeniv.linux.org.uk> 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?
| |