Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH time)
Marc.
On 08/31/2010 12:15 AM, 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
>
A natural read and understanding of pnfs has this logical progression
1st Layoutget and getdeviceinfo (together)
2rd Read/ Write I/O path (could be broken into two sets)
3rd Layoutcommit
4th Layoutreturn
5th Callback Path
Could you elaborate a bit on why you choose to reorder them this way?
> For the 1st wave of functionality, the suggestion is to submit three
> large patches:
>
I would love to see a:
0. Complete STD definitions headers
> 1. Everything that touches NFS common code
> (such as init and uninit pNFS, pnfs_update_layout invocations)
Separation to proc and XDR layers
> 2. Layoutget and getdeviceinfo generic code common to all layout drivers
Is that the high level pnfs.c stuff? then YES nice.
Will this be together with it's invocation at the nfs-vfs files like
inode.c write.c etc.. ?
> 3. File layout specific layoutget and getdeviceinfo
>
You might want to reorder 2 and 3. First submit services which are at first
dead code. Then submit the code that calls them. Are you making a point
in making each patch compilable, runnable through out?
> This means we have about 19 or so of the first pnfs-submit patches that
> need to be squashed into a single patch for ease of review. In
> addition, we found a number of minor issues during the review that need
> to be addressed. We also need to strip out some things that are not
> strictly needed for the first wave of patches, with the intent to
> reintroduce them when the functionality is actually used by objects and
> blocks. It was made clear that including functionality that is not
> required by the File Layout driver at this time is not appropriate. For
> example, io_ops that are no required by the File Layout (and have a
> trivial implementation) are a no-go. The abstraction is best introduced
> when the drivers that actually require it are submitted.
>
> Andy and Fred will email the details of the changes along with the
> patches shortly.
>
> Net-net, no radical changes needed, but a number of small issues that
> need to be addressed before we can start submitting. More details
> coming shortly.
>
> Thanks,
>
> - ricardo
Thanks
Boaz
On Tue, Aug 31, 2010 at 9:58 AM, Boaz Harrosh <[email protected]> wrote:
> On 08/31/2010 12:15 AM, 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
>>
>
> A natural read and understanding of pnfs has this logical progression
>
> 1st Layoutget and getdeviceinfo (together)
> 2rd Read/ Write I/O path (could be broken into two sets)
> 3rd Layoutcommit
> 4th Layoutreturn
> 5th Callback Path
>
> Could you elaborate a bit on why you choose to reorder them this way?
>
Because in your suggested order, the IO code would not work correctly
until the layoutreturn code is added. With our ordering, at each step
there is fully functional code that does not depend for correctness on
future patches. (Note that the layoutcommit code is basically
optional for the file driver, so is last.)
>> For the 1st wave of functionality, the suggestion is to submit three
>> large patches:
>>
>
> I would love to see a:
> 0. Complete STD definitions headers
>
Trond has said that enums taken direct from the spec can include their
full definitions, even if not all are used yet, so those that we
include should be complete.
>> 1. Everything that touches NFS common code
>> =A0 (such as init and uninit pNFS, pnfs_update_layout invocations)
>
> Separation to proc and XDR layers
This will be more like what you ask about below...the invocation of
pnfs code on mount/umount, and calls to pnfs_update_layout.
>
>> 2. Layoutget and getdeviceinfo generic code common to all layout drivers
>
> Is that the high level pnfs.c stuff? then YES nice.
>
Very roughly, the pnfs.c code stripped of anything related to
LAYOUTRETURN, LAYOUTCOMMIT, or needed only for block/object drivers.
> Will this be together with it's invocation at the nfs-vfs files like
> inode.c write.c etc.. ?
>
>> 3. File layout specific layoutget and getdeviceinfo
>>
>
> You might want to reorder 2 and 3. First submit services which are at fir=
st
> dead code. Then submit the code that calls them. Are you making a point
> in making each patch compilable, runnable through out?
>
We've been told to avoid having dead code. So any patch which
includes a function also has callers of that function. Thus we need
to keep the ordering of 2 and 3.
Ignoring how we split up the code for our first submission for the
moment, we should be sending out the actual changes we are making to
the current first ~20 patches of pnfs-submit by the end of the day.
We'll split the code once those changes are reviewed.
Fred
>> This means we have about 19 or so of the first pnfs-submit patches that
>> need to be squashed into a single patch for ease of review. =A0In
>> addition, we found a number of minor issues during the review that need
>> to be addressed. =A0We also need to strip out some things that are not
>> strictly needed for the first wave of patches, with the intent to
>> reintroduce them when the functionality is actually used by objects and
>> blocks. =A0It was made clear that including functionality that is not
>> required by the File Layout driver at this time is not appropriate. =A0F=
or
>> example, io_ops that are no required by the File Layout (and have a
>> trivial implementation) are a no-go. =A0The abstraction is best introduc=
ed
>> when the drivers that actually require it are submitted.
>>
>> Andy and Fred will email the details of the changes along with the
>> patches shortly.
>>
>> Net-net, no radical changes needed, but a number of small issues that
>> need to be addressed before we can start submitting. =A0More details
>> coming shortly.
>>
>> Thanks,
>>
>> - ricardo
>
> Thanks
> Boaz
> _______________________________________________
> NOTE: THIS LIST IS DEPRECATED. =A0Please use [email protected] in=
stead.
> (To subscribe to [email protected]: send "subscribe linux-nfs" in=
the body of a message to [email protected].)
>
> NFSv4 mailing list
> [email protected]
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
>
_______________________________________________
NOTE: THIS LIST IS DEPRECATED. Please use [email protected] instea=
d.
(To subscribe to [email protected]: send "subscribe linux-nfs" in t=
he body of a message to [email protected].)
NFSv4 mailing list
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
Benny Halevy wrote:
Given the low attendance rate, shall we just skip the call this week?
I'll be around but am happy to skip it. The only thing I wanted to bring up
was divergence between pnfs-all-latest and linux.org mainline, and plans and
timetables for pushing upstream. I've brought this up before but was hoping
for an update.
On Aug. 26, 2010, 6:32 +0300, Marc Eshel <[email protected]> wrote:
> Meeting on Thursday 08/26/10 at 9:30 AM pacific time (12:30 PM UMICH time)
Sorry, I can't make it today.
Latest status: pnfs-all-2.6.35-2010-08-24 was released with
the latest pnfs-submit branch, including Andy's renaming work
and his fix of a rcu bug in pnfs deviceid cache found by Fred.
I applied the renames onto the rest of the generic pnfs code and
layout drivers as well as renamed code for the callback path
to match the existing naming convention. I also cleaned up
the patchset itself to get it one step closer for the next step.
Right now I'm rebasing the tree onto 2.6.36-rc1 and will release
the rebased version after giving it a good test.
The next step is reorganize the patchset into shorter runs and
possibly squash together some small patches into bigger ones as
we discussed so to make it easier for review.
Benny
>
> Marc.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
NOTE: THIS LIST IS DEPRECATED. Please use [email protected] instead.
(To subscribe to [email protected]: send "subscribe linux-nfs" in the body of a message to [email protected].)
NFSv4 mailing list
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
On Tue, Aug 31, 2010 at 10:51:11AM -0700, Fred Isaman wrote:
> 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.
I'm not Cristoph, but for changes to generic code anywhere in the kernel
small patches are indeed a requirement, adn they should do exactly one
thing. Adding new code is a different issue from that.
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.
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
This means we have about 19 or so of the first pnfs-submit patches that
need to be squashed into a single patch for ease of review. In
addition, we found a number of minor issues during the review that need
to be addressed. We also need to strip out some things that are not
strictly needed for the first wave of patches, with the intent to
reintroduce them when the functionality is actually used by objects and
blocks. It was made clear that including functionality that is not
required by the File Layout driver at this time is not appropriate. For
example, io_ops that are no required by the File Layout (and have a
trivial implementation) are a no-go. The abstraction is best introduced
when the drivers that actually require it are submitted.
Andy and Fred will email the details of the changes along with the
patches shortly.
Net-net, no radical changes needed, but a number of small issues that
need to be addressed before we can start submitting. More details
coming shortly.
Thanks,
- ricardo
> -----Original Message-----
> From: Benny Halevy [mailto:[email protected]]
> Sent: Thursday, August 26, 2010 12:40 AM
> To: Marc Eshel
> Cc: [email protected]; [email protected]
> Subject: Re: Linux pNFS status meeting 08/26
>
> On Aug. 26, 2010, 6:32 +0300, Marc Eshel <[email protected]>
wrote:
> > Meeting on Thursday 08/26/10 at 9:30 AM pacific time (12:30 PM UMICH
> time)
>
> Sorry, I can't make it today.
> Latest status: pnfs-all-2.6.35-2010-08-24 was released with
> the latest pnfs-submit branch, including Andy's renaming work
> and his fix of a rcu bug in pnfs deviceid cache found by Fred.
>
> I applied the renames onto the rest of the generic pnfs code and
> layout drivers as well as renamed code for the callback path
> to match the existing naming convention. I also cleaned up
> the patchset itself to get it one step closer for the next step.
>
> Right now I'm rebasing the tree onto 2.6.36-rc1 and will release
> the rebased version after giving it a good test.
>
> The next step is reorganize the patchset into shorter runs and
> possibly squash together some small patches into bigger ones as
> we discussed so to make it easier for review.
>
> Benny
>
> >
> > Marc.
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> _______________________________________________
> NOTE: THIS LIST IS DEPRECATED. Please use [email protected]
> instead.
> (To subscribe to [email protected]: send "subscribe linux-nfs"
> in the body of a message to [email protected].)
>
> NFSv4 mailing list
> [email protected]
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
On Tue, Aug 31, 2010 at 9:26 AM, J. Bruce Fields <[email protected]> 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 [email protected] in=
stead.
> (To subscribe to [email protected]: send "subscribe linux-nfs" in=
the body of a message to [email protected].)
>
> NFSv4 mailing list
> [email protected]
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
>
_______________________________________________
NOTE: THIS LIST IS DEPRECATED. Please use [email protected] instea=
d.
(To subscribe to [email protected]: send "subscribe linux-nfs" in t=
he body of a message to [email protected].)
NFSv4 mailing list
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
Meeting on Thursday 08/26/10 at 9:30 AM pacific time (12:30 PM UMICH time)
Marc.
Meeting on Thursday 08/19/10 at 9:30 AM pacific time (12:30 PM UMICH time)
Marc.
On Wed, Aug 11, 2010 at 09:42:21AM -0700, Marc Eshel wrote:
> Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH time)
I won't make it.--b.
On 08/11/2010 01:29 PM, J. Bruce Fields wrote:
> On Wed, Aug 11, 2010 at 09:42:21AM -0700, Marc Eshel wrote:
>> Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH time)
>
> I won't make it.--b.
ditto...
steved.
On Aug. 12, 2010, 2:01 +0300, Steve Dickson <[email protected]> wrote:
>
>
> On 08/11/2010 01:29 PM, J. Bruce Fields wrote:
>> On Wed, Aug 11, 2010 at 09:42:21AM -0700, Marc Eshel wrote:
>>> Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH time)
>>
>> I won't make it.--b.
> ditto...
Given the low attendance rate, shall we just skip the call this week?
Benny
>
> steved.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Ok the meeting is canceled
From:
Benny Halevy <[email protected]>
To:
Marc Eshel <[email protected]>
Cc:
Steve Dickson <[email protected]>, "J. Bruce Fields"
<[email protected]>, [email protected]
Date:
08/12/2010 08:26 AM
Subject:
Re: Linux pNFS status meeting 08/12
On Aug. 12, 2010, 2:01 +0300, Steve Dickson <[email protected]> wrote:
>
>
> On 08/11/2010 01:29 PM, J. Bruce Fields wrote:
>> On Wed, Aug 11, 2010 at 09:42:21AM -0700, Marc Eshel wrote:
>>> Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH
time)
>>
>> I won't make it.--b.
> ditto...
Given the low attendance rate, shall we just skip the call this week?
Benny
>
> steved.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Aug. 12, 2010, 18:42 +0300, Andy Adamson <[email protected]> wrote:
>
> On Aug 12, 2010, at 11:25 AM, Benny Halevy wrote:
>
>> On Aug. 12, 2010, 2:01 +0300, Steve Dickson <[email protected]> wrote:
>>>
>>>
>>> On 08/11/2010 01:29 PM, J. Bruce Fields wrote:
>>>> On Wed, Aug 11, 2010 at 09:42:21AM -0700, Marc Eshel wrote:
>>>>> Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH time)
>>>>
>>>> I won't make it.--b.
>>> ditto...
>>
>> Given the low attendance rate, shall we just skip the call this week?
>
> Here is what I've been up to.
>
>
> Following Fred's most excellent suggestion (at last Thursday's hackers pub meeting), I created a single patch (which I called 'the whole enchilada'!) containing all of the pnfs-submit branch changes, and then proceeded to slice/dice it into logical consumable patches for submission to Trond. This beats the heck out of trying to squash 281 patches together just to re-order all the functionality.
>
> I've attached the battle plan which I'm mostly following, and which although has some detail, is not intended to be a complete list of functions etc. I update the battle plan as I go.
That looks great! Thanks!
>
> I'm currently working on patch #27 called "associate layout segment with nfs_page" in the attachment, so the previous 26 patches mI tagged the tree before I started, and I do a git diff against the tag after each extraction to ensure that the tree is unchanged, and I compile after each patch that I extract from the 'whole enchilada'. I should have the tree down to 40-some patches by this weeks end. The resultant tree will be unchanged from the current pnfs-submit tree, and the last patch will be all the code that is either unused or has no effect.
If you find anything you need to change (like renaming stuff, etc.)
please just send SQUASHME patches on top of the pnfs-submit branch to keep things in sync.
>
> The subject of patch ownership was discussed during the pNFS conference call, but I have not added any authors/signers and would really like some help. There will be more work to do but we will be _much_ closer to a submission stream when I'm done. I think the first submission (this month) should be patches numbered 1-17 in the attachment which provides LAYOUTGET functionality.
As I suggested, since many of us will have contributed to the contents of most of the patches (please
excuse my poor English, I'm not sure I got the tenses right ;-)), let's set the Author: as
"The pNFS Team <[email protected]>" and then we can hopefully derive the sign-offs automatically
using git correlated with the respective patches line numbers.
Benny
>
> If you want to have the call today, it's fine with me.
>
> -->Andy
>
>
>
>
>
>>
>> Benny
>>
>>>
>>> steved.
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Thu, Aug 12, 2010 at 11:55 AM, Benny Halevy <[email protected]> wrote:
> On Aug. 12, 2010, 18:42 +0300, Andy Adamson <[email protected]> wrote:
>>
>> On Aug 12, 2010, at 11:25 AM, Benny Halevy wrote:
>>
>>> On Aug. 12, 2010, 2:01 +0300, Steve Dickson <[email protected]> wrote:
>>>>
>>>>
>>>> On 08/11/2010 01:29 PM, J. Bruce Fields wrote:
>>>>> On Wed, Aug 11, 2010 at 09:42:21AM -0700, Marc Eshel wrote:
>>>>>> Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH time)
>>>>>
>>>>> I won't make it.--b.
>>>> ditto...
>>>
>>> Given the low attendance rate, shall we just skip the call this week?
>>
>> Here is what I've been up to.
>>
>>
>> Following Fred's most excellent suggestion (at last Thursday's hackers pub meeting), I created a single patch (which I called 'the whole enchilada'!) containing all of the pnfs-submit branch changes, and then proceeded to slice/dice it into logical consumable patches for submission to Trond. This beats the heck out of trying to squash 281 patches together just to re-order all the functionality.
>>
>> I've attached the battle plan which I'm mostly following, and which although has some detail, is not intended to be a complete list of functions etc. I update the battle plan as I go.
>
> That looks great! Thanks!
>
>>
>> I'm currently working on patch #27 called "associate layout segment with nfs_page" in the attachment, so the previous 26 patches mI tagged the tree before I started, and I do a git diff against the tag after each extraction to ensure that the tree is unchanged, and I compile after each patch that I extract from the 'whole enchilada'. I should have the tree down to 40-some patches by this weeks end. The resultant tree will be unchanged from the current pnfs-submit tree, and the last patch will be all the code that is either unused or has no effect.
>
>
> If you find anything you need to change (like renaming stuff, etc.)
> please just send SQUASHME patches on top of the pnfs-submit branch to keep things in sync.
OK. I was planning on sending you the 'new' pnfs-submit tree patchset
that left the resultant tree unchanged, and then do renames, etc on
top - just so we know where we are.
>
>>
>> The subject of patch ownership was discussed during the pNFS conference call, but I have not added any authors/signers and would really like some help. There will be more work to do but we will be _much_ closer to a submission stream when I'm done. I think the first submission (this month) should be patches numbered 1-17 in the attachment which provides LAYOUTGET functionality.
>
> As I suggested, since many of us will have contributed to the contents of most of the patches (please
> excuse my poor English, I'm not sure I got the tenses right ;-)), let's set the Author: as
> "The pNFS Team <[email protected]>" and then we can hopefully derive the sign-offs automatically
> using git correlated with the respective patches line numbers.
OK. I'll just add your suggested Author and then send you the tree so
you can help with the sign-offs list.
-->Andy
>
> Benny
>
>>
>> If you want to have the call today, it's fine with me.
>>
>> -->Andy
>>
>>
>>
>>
>>
>>>
>>> Benny
>>>
>>>>
>>>> steved.
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>> the body of a message to [email protected]
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Aug. 12, 2010, 18:59 +0300, "William A. (Andy) Adamson" <[email protected]> wrote:
> On Thu, Aug 12, 2010 at 11:55 AM, Benny Halevy <[email protected]> wrote:
>> On Aug. 12, 2010, 18:42 +0300, Andy Adamson <[email protected]> wrote:
>>>
>>> On Aug 12, 2010, at 11:25 AM, Benny Halevy wrote:
>>>
>>>> On Aug. 12, 2010, 2:01 +0300, Steve Dickson <[email protected]> wrote:
>>>>>
>>>>>
>>>>> On 08/11/2010 01:29 PM, J. Bruce Fields wrote:
>>>>>> On Wed, Aug 11, 2010 at 09:42:21AM -0700, Marc Eshel wrote:
>>>>>>> Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH time)
>>>>>>
>>>>>> I won't make it.--b.
>>>>> ditto...
>>>>
>>>> Given the low attendance rate, shall we just skip the call this week?
>>>
>>> Here is what I've been up to.
>>>
>>>
>>> Following Fred's most excellent suggestion (at last Thursday's hackers pub meeting), I created a single patch (which I called 'the whole enchilada'!) containing all of the pnfs-submit branch changes, and then proceeded to slice/dice it into logical consumable patches for submission to Trond. This beats the heck out of trying to squash 281 patches together just to re-order all the functionality.
>>>
>>> I've attached the battle plan which I'm mostly following, and which although has some detail, is not intended to be a complete list of functions etc. I update the battle plan as I go.
>>
>> That looks great! Thanks!
>>
>>>
>>> I'm currently working on patch #27 called "associate layout segment with nfs_page" in the attachment, so the previous 26 patches mI tagged the tree before I started, and I do a git diff against the tag after each extraction to ensure that the tree is unchanged, and I compile after each patch that I extract from the 'whole enchilada'. I should have the tree down to 40-some patches by this weeks end. The resultant tree will be unchanged from the current pnfs-submit tree, and the last patch will be all the code that is either unused or has no effect.
>>
>>
>> If you find anything you need to change (like renaming stuff, etc.)
>> please just send SQUASHME patches on top of the pnfs-submit branch to keep things in sync.
>
> OK. I was planning on sending you the 'new' pnfs-submit tree patchset
> that left the resultant tree unchanged, and then do renames, etc on
> top - just so we know where we are.
>
That's even better :)
I'm back on my feet (metaphorically) now after the move
so I'm ready for your patches, feel free to throw them at me any time :)
Benny
>>
>>>
>>> The subject of patch ownership was discussed during the pNFS conference call, but I have not added any authors/signers and would really like some help. There will be more work to do but we will be _much_ closer to a submission stream when I'm done. I think the first submission (this month) should be patches numbered 1-17 in the attachment which provides LAYOUTGET functionality.
>>
>> As I suggested, since many of us will have contributed to the contents of most of the patches (please
>> excuse my poor English, I'm not sure I got the tenses right ;-)), let's set the Author: as
>> "The pNFS Team <[email protected]>" and then we can hopefully derive the sign-offs automatically
>> using git correlated with the respective patches line numbers.
>
> OK. I'll just add your suggested Author and then send you the tree so
> you can help with the sign-offs list.
>
> -->Andy
>
>>
>> Benny
>>
>>>
>>> If you want to have the call today, it's fine with me.
>>>
>>> -->Andy
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Benny
>>>>
>>>>>
>>>>> steved.
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>> the body of a message to [email protected]
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>> the body of a message to [email protected]
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>