All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Tucker <tom@opengridcomputing.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: NeilBrown <neilb@suse.de>,
	nfs@lists.sourceforge.net, Greg Banks <gnb@sgi.com>
Subject: Re: [RFC, PATCH 3/3] knfsd: Modify write_ports to use	svc_find_xprt service
Date: Thu, 11 Oct 2007 10:27:08 -0500	[thread overview]
Message-ID: <1192116428.7491.5.camel@trinity.ogc.int> (raw)
In-Reply-To: <20071011152512.GB17468@fieldses.org>

On Thu, 2007-10-11 at 11:25 -0400, J. Bruce Fields wrote:
> On Thu, Oct 11, 2007 at 12:11:26AM -0500, Tom Tucker wrote:
> > What's the most efficient way for you to accept fixes/changes? I've been
> > going incremental because it's easy on me :-). Is this the best option for
> > you?
> 
> Well, the problem is that there's two different histories we want, and
> no tool really makes it easy (or perhaps can make it really easy) to
> track them both:
> 
> 	- There's the final cleaned-up series that we want submitted.
> 	- There's the incremental changes that are made to fix problems
> 	  in the original series.
> 
> A lot of people deal with this by just resubmitting the whole thing
> (usually as a big mailbomb each time) with a changelog in the 0/n
> message that explains what changed since the previous submission.
> 
> But in practice I think that means we lose some follow-up review because
> it's harder for reviewers in the previous round to plow through the
> whole series from the start each time.  And it looks like Greg is still
> spotting some problems that might not have been otherwise.  So that's
> working.
> 
> So for now I guess I'll try what seems to be Andrew's approach--take
> incremental patches, then merge them in before the end.  If that turns
> out to be too hard, I'll complain.

np. I've got a stacked git tree that has the whole set, so I can flatten
it or keep it at your discretion. 

> 
> > Regarding patch #6, I think the svc_find_xprt API _may_ be ok, but the
> > implementation was bogus (sorry). I _think_ the implementation is fixed in
> > the latest incremental. Greg can confirm.
> 
> OK!
> 
> --b.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2007-10-11 15:28 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-11  2:23 [RFC, PATCH 0/3] svc: gnb review cleanup for transport switch Tom Tucker
2007-10-11  2:28 ` [RFC, PATCH 1/3] svc: Change sockaddr to sockaddr_storage in svc_create_xprt Tom Tucker
2007-10-11  2:28 ` [RFC,PATCH 2/3] svc: Fix bugs in svc_find_xprt Tom Tucker
2007-10-11  2:29 ` [RFC, PATCH 3/3] knfsd: Modify write_ports to use svc_find_xprt service Tom Tucker
2007-10-11  3:00   ` Neil Brown
2007-10-11  3:46     ` J. Bruce Fields
2007-10-11  5:09       ` Neil Brown
2007-10-11  5:26         ` Greg Banks
2007-10-11  5:37           ` Neil Brown
2007-10-11 14:56         ` J. Bruce Fields
2007-10-11  5:11       ` Tom Tucker
2007-10-11 15:25         ` J. Bruce Fields
2007-10-11 15:27           ` Tom Tucker [this message]
2007-10-11 17:04             ` J. Bruce Fields
2007-10-11  5:25 ` [RFC, PATCH 0/3] svc: gnb review cleanup for transport switch Greg Banks
2007-10-11 17:09   ` J. Bruce Fields
2007-10-11 20:30 ` J. Bruce Fields
2007-10-11 20:53   ` Tom Tucker
2007-10-11 21:14   ` Tom Tucker
2007-10-11 22:04   ` Tom Tucker
2007-10-11 22:08     ` J. Bruce Fields
2007-10-12 15:17       ` Tom Tucker
2007-10-12 15:41         ` J. Bruce Fields
2007-10-12 16:27           ` Tom Tucker
2007-10-12 21:40   ` Tom Tucker
2007-10-12 22:03     ` J. Bruce Fields
2007-10-12 22:30       ` J. Bruce Fields
2007-10-13  3:48         ` J. Bruce Fields
2007-10-13 12:35           ` Tom Tucker

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=1192116428.7491.5.camel@trinity.ogc.int \
    --to=tom@opengridcomputing.com \
    --cc=bfields@fieldses.org \
    --cc=gnb@sgi.com \
    --cc=neilb@suse.de \
    --cc=nfs@lists.sourceforge.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.