Return-Path: In-Reply-To: <20100831162648.GF3071@fieldses.org> References: <4C761A61.2070203@panasas.com> <273FE88A07F5D445824060902F7003440C5CDD52@SACMVEXC1-PRD.hq.netapp.com> <20100831162648.GF3071@fieldses.org> Date: Tue, 31 Aug 2010 10:51:11 -0700 Message-ID: Subject: Re: Linux pNFS status meeting 08/26 From: Fred Isaman To: "J. Bruce Fields" Cc: linux-nfs@vger.kernel.org, nfsv4@linux-nfs.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Sender: nfsv4-bounces@linux-nfs.org Errors-To: nfsv4-bounces@linux-nfs.org MIME-Version: 1.0 List-ID: On Tue, Aug 31, 2010 at 9:26 AM, J. Bruce Fields wro= te: > On Mon, Aug 30, 2010 at 02:15:43PM -0700, Labiaga, Ricardo wrote: >> Last week Andy, Fred, Trond, and I were physically in the same location, >> so we took the opportunity to review the first set of patches in the >> pnfs-submit branch and further discussed the best way to proceed with >> the submission. =A0For ease of review, Trond reiterated that we submit o= ur >> patches in waves of functionality and that they be submitted as a set of >> few large patches. >> >> The proposal is to submit the functionality in the following order: >> >> 1st Layoutget and getdeviceinfo (together) >> 2nd Layoutreturn >> 3rd Read/ Write I/O path (could be broken into two sets) >> 4th Callback Path >> 5th Layoutcommit >> >> For the 1st wave of functionality, the suggestion is to submit three >> large patches: >> >> 1. Everything that touches NFS common code >> =A0 (such as init and uninit pNFS, pnfs_update_layout invocations) >> 2. Layoutget and getdeviceinfo generic code common to all layout drivers >> 3. File layout specific layoutget and getdeviceinfo > > I understand large patches for the latter two, but for the first, might > it be worth keeping smaller patches? =A0Changes to common code seem most > at risk of breaking existing functionality. =A0And they might be > individually testable (since you can test for regressions), as opposed to > the new stuff that may be impossible to test until it's all applied. > Note that the not much touches the common code, especially in our first submission, so it will be a fairly small patch, which we will not be adverse to breaking up at reviewers request. Right now we are trying to accommodate Cristoph's request for larger patches combined with Trond's request for small, easy to review patches for anything that touches common code. Fred > But that's all just generalities--if people who've looked at the patches > don't think they split up sensibly, then fine. > > --b. > _______________________________________________ > NOTE: THIS LIST IS DEPRECATED. =A0Please use linux-nfs@vger.kernel.org in= stead. > (To subscribe to linux-nfs@vger.kernel.org: send "subscribe linux-nfs" in= the body of a message to majordomo@vger.kernel.org.) > > NFSv4 mailing list > NFSv4@linux-nfs.org > http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 > _______________________________________________ NOTE: THIS LIST IS DEPRECATED. Please use linux-nfs@vger.kernel.org instea= d. (To subscribe to linux-nfs@vger.kernel.org: send "subscribe linux-nfs" in t= he body of a message to majordomo@vger.kernel.org.) NFSv4 mailing list NFSv4@linux-nfs.org http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4