From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [git pull] vfs part 3
Date: Fri, 17 Apr 2015 16:50:17 +0100 [thread overview]
Message-ID: <20150417155017.GB889@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFyuTraku3ijjZRQdcmaieub_cntAvfknE1wyxibbc0D2Q@mail.gmail.com>
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?
prev parent reply other threads:[~2015-04-17 15:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 1:04 [git pull] vfs part 3 Al Viro
2015-04-17 3:26 ` Linus Torvalds
2015-04-17 15:50 ` Al Viro [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150417155017.GB889@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.