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. But that's all just generalities--if people who've looked at the patches don't think they split up sensibly, then fine. --b. -- 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
