From: Randy Dunlap <rdunlap@xenotime.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Sage Weil <sage@newdream.net>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
yehuda@newdream.net
Subject: Re: ceph code review
Date: Thu, 03 Dec 2009 13:22:45 -0800 [thread overview]
Message-ID: <4B182C25.9070008@xenotime.net> (raw)
In-Reply-To: <20091203123111.eef5a398.akpm@linux-foundation.org>
Andrew Morton wrote:
> 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.
also, many of us just don't have time to review (large) patches
like we did in the past. The number of patch reviewers is way down
in my non-statistical estimate. :(
~Randy
next prev parent reply other threads:[~2009-12-03 21:22 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
2009-12-03 21:22 ` Randy Dunlap [this message]
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=4B182C25.9070008@xenotime.net \
--to=rdunlap@xenotime.net \
--cc=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).