linux-kernel - Re: [PATCH 0/7] Permit filesystem local caching and NFS superblock sharing [try #13]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20060831102127.8fb9a24b.akpm@osdl.org>
Date:	Thu, 31 Aug 2006 10:21:27 -0700
From:	Andrew Morton <akpm@...l.org>
To:	David Howells <dhowells@...hat.com>
Cc:	torvalds@...l.org, steved@...hat.com, trond.myklebust@....uio.no,
	linux-fsdevel@...r.kernel.org, linux-cachefs@...hat.com,
	nfsv4@...ux-nfs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] Permit filesystem local caching and NFS superblock
 sharing [try #13]

On Thu, 31 Aug 2006 10:58:30 +0100
David Howells <dhowells@...hat.com> wrote:

> Andrew Morton <akpm@...l.org> wrote:
> 
> > - Send fine-grained incremental patches.  It's OK to do complete
> >   replacement patchsets when the code is new, but this stuff is supposed to
> >   be stabilised.
> 
> I thought the code was still officially *new*.

It's been floating around for ages; we want it to become *old*, showing a
decreasing rate of change.

> As I understood things from what you said, you delegated responsibility for my
> patches on to Trond, who hasn't taken them yet.

Trond merged the large nfs-affecting ones; I don't know if he intends to
handle the non-nfs bulk of the work though.

I doesn't matter, really - I'll frequently carry features with a plan to
send them into a subsystem tree.  Or Trond could duck it and I can send the
patches direct to Linus after git-nfs has merged.

Either way, the patches which are presently in -mm are "in the pipeline" -
they're the ones which people are testing (for compile, at least) and
reviewing (hah).  If we decide to send them into Trond then I'll add them
to my things-to-spam-maintainers-with pile.

Your CONFIG_BLOCK patches did a decent job of trashing your
fs-cache-make-kafs-* patches, btw.  What's up with that?  OK, it's sensible
for people to work against mainline but the net effect of doing that is to
create a mess for other people to clean up.

>  He has further delegated
> review responsibility on to Christoph, so I've been consolidating my patches
> to make it easier for Christoph (or whoever) to do so.

These patches are quite large and complex.  Frankly, I doubt if Trond or
Christoph have the bandwidth to review them.  It would be excellent if they
were able to, but...

We have a large coder-versus-reviewer imbalance, especially in the
filesystems area.  cf reiser4.

> So, as I understand the situation, my patches won't go anywhere until
> Christoph ACKs them and Trond takes them into his tree.  If this isn't so,
> please clarify the situation.
> 

If Christoph acks them then I can send them to Trond or Linus, at Trond's
option.

Or I can butt out, drop the patches, wait for them to turn up in Trond's
tree, at your option.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/