From: Andrew Morton <akpm@linux-foundation.org>
To: Sage Weil <sage@newdream.net>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
yehuda@newdream.net
Subject: Re: ceph code review
Date: Thu, 3 Dec 2009 12:31:11 -0800 [thread overview]
Message-ID: <20091203123111.eef5a398.akpm@linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0912011648590.5806@cobra.newdream.net>
On Thu, 3 Dec 2009 12:27:23 -0800 (PST)
Sage Weil <sage@newdream.net> wrote:
> On Tue, 29 Sep 2009, Andrew Morton wrote:
> > The code looks reasonable to me. Unless others emit convincing
> > squeaks, please ask Stephen to include your git tree into linux-next
> > sometime within the next month, then send Linus a pull request for
> > 2.6.33.
>
> The code has seen 70 odd patches since then. Mostly small fixes and
> cleanups, and a handful of larger changes. Should these see the light of
> LKML before I send a pull request of Linus? (So far they've just gone out
> to the ceph commit list.) I don't want to spam everyone with a huge series
> fixing up as yet unmerged code, but I'm not sure that review on the ceph
> lists is sufficient, given the frequency with which I see fs series on
> LKML...
>
> What are the best practices here?
>
My preference would be to fold all the little fixes back into the main
patch series then reissue it all as a nice patchset for people to
re-review.
But that practice has largely gone by the wayside in recent years
because of git-enforced restrictions :(. It might muck up your
development history to an unacceptable-to-you extent also, dunno.
next prev parent reply other threads:[~2009-12-03 20:31 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-22 17:38 [PATCH 00/21] ceph distributed file system client Sage Weil
2009-09-22 17:38 ` [PATCH 01/21] ceph: documentation Sage Weil
2009-09-22 17:38 ` [PATCH 02/21] ceph: on-wire types Sage Weil
2009-09-22 17:38 ` [PATCH 03/21] ceph: client types Sage Weil
2009-09-22 17:38 ` [PATCH 04/21] ceph: ref counted buffer Sage Weil
2009-09-22 17:38 ` [PATCH 05/21] ceph: super.c Sage Weil
2009-09-22 17:38 ` [PATCH 06/21] ceph: inode operations Sage Weil
2009-09-22 17:38 ` [PATCH 07/21] ceph: directory operations Sage Weil
2009-09-22 17:38 ` [PATCH 08/21] ceph: file operations Sage Weil
2009-09-22 17:38 ` [PATCH 09/21] ceph: address space operations Sage Weil
2009-09-22 17:38 ` [PATCH 10/21] ceph: MDS client Sage Weil
2009-09-22 17:38 ` [PATCH 11/21] ceph: OSD client Sage Weil
2009-09-22 17:38 ` [PATCH 12/21] ceph: CRUSH mapping algorithm Sage Weil
2009-09-22 17:38 ` [PATCH 13/21] ceph: monitor client Sage Weil
2009-09-22 17:38 ` [PATCH 14/21] ceph: capability management Sage Weil
2009-09-22 17:38 ` [PATCH 15/21] ceph: snapshot management Sage Weil
2009-09-22 17:38 ` [PATCH 16/21] ceph: messenger library Sage Weil
2009-09-22 17:38 ` [PATCH 17/21] ceph: message pools Sage Weil
2009-09-22 17:38 ` [PATCH 18/21] ceph: nfs re-export support Sage Weil
2009-09-22 17:38 ` [PATCH 19/21] ceph: ioctls Sage Weil
2009-09-22 17:38 ` [PATCH 20/21] ceph: debugfs Sage Weil
2009-09-22 17:38 ` [PATCH 21/21] ceph: Kconfig, Makefile Sage Weil
2009-10-02 4:18 ` [PATCH 19/21] ceph: ioctls Andi Kleen
2009-10-02 15:55 ` Sage Weil
2009-10-02 16:36 ` Andi Kleen
2009-09-30 0:15 ` [PATCH 06/21] ceph: inode operations Andrew Morton
2009-09-30 17:45 ` Sage Weil
2009-12-03 20:27 ` ceph code review Sage Weil
2009-12-03 20:31 ` Andrew Morton [this message]
2009-12-03 21:22 ` Randy Dunlap
2009-09-30 0:13 ` [PATCH 05/21] ceph: super.c Andrew Morton
2009-09-30 0:02 ` [PATCH 04/21] ceph: ref counted buffer Andrew Morton
2009-09-22 18:08 ` [PATCH 03/21] ceph: client types Joe Perches
2009-09-29 23:57 ` Andrew Morton
2009-09-30 17:41 ` Sage Weil
2009-09-22 18:01 ` [PATCH 02/21] ceph: on-wire types Joe Perches
2009-09-22 18:21 ` Sage Weil
2009-09-29 23:52 ` Andrew Morton
2009-09-30 17:40 ` Sage Weil
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=20091203123111.eef5a398.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sage@newdream.net \
--cc=yehuda@newdream.net \
/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).