From: "J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [RFC,
	PATCH 3/3] knfsd: Modify write_ports to use	svc_find_xprt service
Date: Thu, 11 Oct 2007 13:04:16 -0400
Message-ID: <20071011170416.GA22823@fieldses.org>
References: <20071011034608.GC6684@fieldses.org>
	<C3331AAE.3C378%tom@opengridcomputing.com>
	<20071011152512.GB17468@fieldses.org>
	<1192116428.7491.5.camel@trinity.ogc.int>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: NeilBrown <neilb@suse.de>, nfs@lists.sourceforge.net,
	Greg Banks <gnb@sgi.com>
To: Tom Tucker <tom@opengridcomputing.com>
In-Reply-To: <1192116428.7491.5.camel@trinity.ogc.int>
Sender: nfs-bounces@lists.sourceforge.net
Errors-To: nfs-bounces@lists.sourceforge.net

On Thu, Oct 11, 2007 at 10:27:08AM -0500, Tom Tucker wrote:
> On Thu, 2007-10-11 at 11:25 -0400, J. Bruce Fields wrote:
> > 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. 

Well, if you want to be a total hero and do *both* the incremental
patches and also keep a series with the merged in as appropriate, that'd
be great.  So given a series of patches:

	1/3	clean up frobnicator
	2/3	introduce new frobnicator-next-generation api
	3/3	move users to frobnicator-next-generation

if you had an incremental fix, you could send it out like:

	0/1	"Oops, here's a fix for my last series.  I also have a
		fixed version of the series here: git://..."
	1/1	rename frobnicator-next-generation to frobnicator-new

and then git://... would have a series that looked like:

	1/3	clean up frobnicator
	2/3	introduce new frobnicator-new api
	3/3	move users to frobnicator-new

I'd both apply the incremental patch and fetch the modified series, diff
them to make sure they both got the same result, then take the modified
series and throw away the old one.

Anyway, for now I think I've caught up to your latest here:

	git://linux-nfs.org/~bfields	server-xprt-switch

mostly left separated out at this point, except the two I fooled with
yesterday.

--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