On Tue, Aug 31, 2010 at 9:26 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > 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. For ease of review, Trond reiterated that we submit our >> 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 >> (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? Changes to common code seem most > at risk of breaking existing functionality. And 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. Please use linux-nfs@xxxxxxxxxxxxxxx instead. > (To subscribe to linux-nfs@xxxxxxxxxxxxxxx: send "subscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxxx) > > NFSv4 mailing list > NFSv4@xxxxxxxxxxxxx > http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
