From: Al Viro <viro@ZenIV.linux.org.uk>
To: Mike Marshall <hubcap@omnibond.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Martin Brandenburg <martin@omnibond.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [git pull] orangefs bugfixes for rc2
Date: Thu, 31 Mar 2016 23:59:07 +0100 [thread overview]
Message-ID: <20160331225907.GZ17997@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAOg9mSQjSV6eT7OiNV_GrM5bHE-JeSqyBWTdVxd-DxUuDjdb_g@mail.gmail.com>
On Thu, Mar 31, 2016 at 05:06:17PM -0400, Mike Marshall wrote:
> sorry to follow up my own post... perhaps we should
> point our pull requests at Al and base them on one
> of Al's trees? I'm sure all this should be easy, we're
> just clumsy 'cause we're new...
Only in cases when you depend on something in my tree. And even then it would
be better to discuss the situation so I could put the stuff you really
need into a never-modified branch, so that both your tree and mine would
contain a merge from it.
It varies for different subsystems - e.g. all networking stuff tends to
go through the davem's tree; he pulls from submaintainers and feeds the
results to Linus. I've no idea how he survives that kind of load and
I would certainly prefer to avoid the same role for vfs and filesystems.
IMO it's a logistical nightmare; Dave somehow manages to cope with that,
but I've no idea how to do that.
I would very much prefer to have the inter-tree dependencies minimized, as
far as vfs and filesystems are concerned. By default I reorder the stuff
in vfs.git as I see fit; if something is needed for another tree, I prefer
to add a separate (and usually short) branch with just the required stuff
and a promise to never rebase/reorder/etc.
AFAICS, nothing in this pull request depends on anything outside of what
went into mainline just before -rc1, so I would probably just based that
branch at 4599649 and added fixes on top of that. No need to backmerge unless
you need something that went into mainline in the meanwhile (and backmerge
in that case would better be limited to what you need - e.g. "we need the
stuff pulled into mainline from <branch> at <sha1>, so we merge that branch").
Or just base it off -rc1 - that'll give you everything that went into mainline
in given merge window...
next prev parent reply other threads:[~2016-03-31 22:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-31 16:17 [git pull] orangefs bugfixes for rc2 Martin Brandenburg
2016-03-31 19:27 ` Linus Torvalds
2016-03-31 21:01 ` Mike Marshall
2016-03-31 21:06 ` Mike Marshall
2016-03-31 22:11 ` Linus Torvalds
2016-03-31 22:59 ` Al Viro [this message]
2016-04-01 1:19 ` Theodore Ts'o
2016-04-01 19:49 ` Martin Brandenburg
2016-04-01 22:35 ` Linus Torvalds
2016-04-01 23:29 ` Mike Marshall
2016-04-01 23:23 ` Joe Perches
2016-04-02 1:32 ` Martin Brandenburg
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=20160331225907.GZ17997@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=hubcap@omnibond.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin@omnibond.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).