Linus,
Please pull two bugfixes for OrangeFS.
One fixes a rather serious reference counting bug and one fixes a typo
which would stop the latest stable userspace client from starting up.
Thanks,
-- Martin
The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:
Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)
are available in the git repository at:
https://github.com/martinbrandenburg/linux.git for-linus
for you to fetch changes up to 878dfd3210e0bfc047995022de3091724ea9a5f6:
orangefs: minimum userspace version is 2.9.3 (2016-03-31 12:06:00 -0400)
----------------------------------------------------------------
Martin Brandenburg (2):
orangefs: don't put readdir slot twice
orangefs: minimum userspace version is 2.9.3
fs/orangefs/dir.c | 8 +++-----
fs/orangefs/protocol.h | 2 +-
2 files changed, 4 insertions(+), 6 deletions(-)
On Thu, Mar 31, 2016 at 11:17 AM, Martin Brandenburg
<[email protected]> wrote:
>
> Please pull two bugfixes for OrangeFS.
I *really* want signed tags when pulling from github or similar open
hosting sites.
So can you please re-do the pull request, but rather than just a plain
branch, use
"git tag -s"
to create a signed tag for me to pull?
Even if your key doesn't end up being connected to other kernel
developers (I have no idea), I'll be able to see that I'm pulling from
the same person, and presumably you and Mike can sign (or already have
signed) each others keys etc so that eventually that connection is
visible too.
Linus
Hi everyone...
I'm at the Linux Foundation meeting at Tahoe, I've been
asking around some, I know we need to do things differently
now that we are upstream... there's several things in my mailbox
besides what Martin has done that need to go up...
I think we need, during the rc period, to post our patches here
in case anyone wants to look at them, put them in our for-next
branch so that all the robots can test them, and then after
a week or so post a pull request similar to Martin's for them,
but from our kernel.org tree... pull requests for reviewed code
from kernel.org doesn't need signed tags...
Does that sound mostly right?
-Mike
On Thu, Mar 31, 2016 at 3:27 PM, Linus Torvalds
<[email protected]> wrote:
> On Thu, Mar 31, 2016 at 11:17 AM, Martin Brandenburg
> <[email protected]> wrote:
>>
>> Please pull two bugfixes for OrangeFS.
>
> I *really* want signed tags when pulling from github or similar open
> hosting sites.
>
> So can you please re-do the pull request, but rather than just a plain
> branch, use
>
> "git tag -s"
>
> to create a signed tag for me to pull?
>
> Even if your key doesn't end up being connected to other kernel
> developers (I have no idea), I'll be able to see that I'm pulling from
> the same person, and presumably you and Mike can sign (or already have
> signed) each others keys etc so that eventually that connection is
> visible too.
>
> Linus
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...
-Mike
On Thu, Mar 31, 2016 at 5:01 PM, Mike Marshall <[email protected]> wrote:
> Hi everyone...
>
> I'm at the Linux Foundation meeting at Tahoe, I've been
> asking around some, I know we need to do things differently
> now that we are upstream... there's several things in my mailbox
> besides what Martin has done that need to go up...
>
> I think we need, during the rc period, to post our patches here
> in case anyone wants to look at them, put them in our for-next
> branch so that all the robots can test them, and then after
> a week or so post a pull request similar to Martin's for them,
> but from our kernel.org tree... pull requests for reviewed code
> from kernel.org doesn't need signed tags...
>
> Does that sound mostly right?
>
> -Mike
>
> On Thu, Mar 31, 2016 at 3:27 PM, Linus Torvalds
> <[email protected]> wrote:
>> On Thu, Mar 31, 2016 at 11:17 AM, Martin Brandenburg
>> <[email protected]> wrote:
>>>
>>> Please pull two bugfixes for OrangeFS.
>>
>> I *really* want signed tags when pulling from github or similar open
>> hosting sites.
>>
>> So can you please re-do the pull request, but rather than just a plain
>> branch, use
>>
>> "git tag -s"
>>
>> to create a signed tag for me to pull?
>>
>> Even if your key doesn't end up being connected to other kernel
>> developers (I have no idea), I'll be able to see that I'm pulling from
>> the same person, and presumably you and Mike can sign (or already have
>> signed) each others keys etc so that eventually that connection is
>> visible too.
>>
>> Linus
On Thu, Mar 31, 2016 at 4:06 PM, Mike Marshall <[email protected]> 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...
No, for stuff that is entirely internal to a filesystem, the
filesystem maintainers should preferably strive to be as independent
of all other trees as possible.
That means that the base you use should generally be either your own
previous top-of-tree (ie without any back-merges from me or other
trees at all: so your branch only contains your own work), or if it
ends up being more convenient some "well-defined" general release (ie
a major release like 4.5, or a later rc like rc4+ that is starting to
be considered reasonably stable).
For bug-fix pulls, the best base tends to be your own tree that you
asked me to pull during the merge window, while then "new development
for the next version" might be some known base.
Of course, since orangefs just got merged, you can't use 4.5 as a
base, but then going forward when you start doing development that you
expect to be merged for 4.7, you might want to use 4.6 as a base for
that.
Right now, using rc1 as a base for fixes would also be reasonable,
exactly because you can't use any older release. But in general it's
best to try to have better starting points than rc1 (or worse yet,
some "random daily point from Linus") which may have undiscovered bugs
etc.
Linus
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...
On Thu, Mar 31, 2016 at 05:01:47PM -0400, Mike Marshall wrote:
>
> but from our kernel.org tree... pull requests for reviewed code
> from kernel.org doesn't need signed tags...
Signed tags are considered best practice, even if your git tree is
hosted on git.kernel.org. One of the reasons for this is because even
after Linus merges your changes, someone can independently verify that
the changes came from you; they don't have to trust Linus or whatever
git server they happened to pull the tree from. For example, try
running the command:
git show --show-signature faeb20ecfa398b043c3224607f512c009c51653d
You'll see something like this:
commit faeb20ecfa398b043c3224607f512c009c51653d
merged tag 'ext4_for_linus'
gpg: Signature made Wed 16 Mar 2016 05:25:58 PM EDT
gpg: using RSA key 0xF2F95956950D81A3
gpg: Good signature from "Theodore Ts'o <[email protected]>" [ultimate]
gpg: aka "Theodore Ts'o <[email protected]>" [ultimate]
gpg: aka "Theodore Ts'o <[email protected]>" [ultimate]
Primary key fingerprint: 3AB0 57B7 E78D 945C 8C55 91FB D36F 769B C118 04F0
Subkey fingerprint: 2B69 B954 DBFE 0879 2881 37C9 F2F9 5956 950D 81A3
Merge: 364e8dd 0304688
Author: Linus Torvalds <[email protected]>
Date: Thu Mar 17 16:31:18 2016 -0700
Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
Pull ext4 updates from Ted Ts'o:
"Performance improvements in SEEK_DATA and xattr scalability
improvements, plus a lot of clean ups and bug fixes"
So while a signed tag might not be _required_, it's definitely
preferred.
Cheers,
- Ted
Let's try this again...
The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:
Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)
are available in the git repository at:
https://github.com/martinbrandenburg/linux.git tags/for-linus
for you to fetch changes up to 878dfd3210e0bfc047995022de3091724ea9a5f6:
orangefs: minimum userspace version is 2.9.3 (2016-03-31 12:06:00 -0400)
----------------------------------------------------------------
Two bugfixes for OrangeFS.
One is a reference counting bug and the other is a typo in client
minimum version.
----------------------------------------------------------------
Martin Brandenburg (2):
orangefs: don't put readdir slot twice
orangefs: minimum userspace version is 2.9.3
fs/orangefs/dir.c | 8 +++-----
fs/orangefs/protocol.h | 2 +-
2 files changed, 4 insertions(+), 6 deletions(-)
On Fri, Apr 1, 2016 at 2:49 PM, Martin Brandenburg <[email protected]> wrote:
> Let's try this again...
Ok, pulled.
That's a brand-spanking new key you have there, can you try to get
that mutually signed with at least Mike, possibly other kernel
developers? Depending on where you are physically, that may be either
easy or hard.
Linus
Hello Martin.
Here's an orangefs patch I think should be applied:
https://patchwork.kernel.org/patch/8676461/
You were not cc'd on this as you are not listed as a
maintainer for orangefs.
Should you be?
It will be easy for him to get me to sign it when I get home from the LF Summit.
I am, more slowly than Martin, working on another pull request for
you, mostly with
some stuff from the linux-next robots. I'll guess I should base my
pull request on rc2 since
that will have Martin's patches in them?
-Mike "I'm not ignoring Joe Perches <g>"
On Fri, Apr 1, 2016 at 6:35 PM, Linus Torvalds
<[email protected]> wrote:
> On Fri, Apr 1, 2016 at 2:49 PM, Martin Brandenburg <[email protected]> wrote:
>> Let's try this again...
>
> Ok, pulled.
>
> That's a brand-spanking new key you have there, can you try to get
> that mutually signed with at least Mike, possibly other kernel
> developers? Depending on where you are physically, that may be either
> easy or hard.
>
> Linus
On Fri, 1 Apr 2016, Joe Perches wrote:
> Hello Martin.
>
> Here's an orangefs patch I think should be applied:
> https://patchwork.kernel.org/patch/8676461/
>
> You were not cc'd on this as you are not listed as a
> maintainer for orangefs.
>
> Should you be?
>
>
Mike is listed AFAIK.
He's the maintainer, but he's away this week, so I went
ahead and sent these in.
I believe he has your patches in his tree.
-- Martin