On 2011-09-19 05:06, Myklebust, Trond wrote: >> -----Original Message----- >> From: Jim Rees [mailto:rees@xxxxxxxxx] >> Sent: Sunday, September 18, 2011 10:05 PM >> To: Myklebust, Trond >> Cc: Benny Halevy; Peng Tao; linux-nfs@xxxxxxxxxxxxxxx; peter honeyman >> Subject: Re: [PATCH] pnfsblock: add missing rpc_put_mount and path_put >> >> Myklebust, Trond wrote: >> >> > -----Original Message----- >> > From: Benny Halevy [mailto:bhalevy@xxxxxxxxxx] >> > Sent: Wednesday, September 14, 2011 6:20 AM >> > To: Jim Rees; Peng Tao; Myklebust, Trond >> > Cc: linux-nfs@xxxxxxxxxxxxxxx; peter honeyman >> > Subject: Re: [PATCH] pnfsblock: add missing rpc_put_mount and > path_put >> > >> > We need to decide on a process here :) >> > If we would like to maintain a staging tree in front of Trond's > then >> to simplify >> > merging and rebasing, fixes to code that's already upstream, i.e. > in >> linux-2.6 >> > or already queued in nfs-2.6, that we decide to send to Trond > ahead of >> > queue need to be queued in front of stuff in the staging tree and > the >> latter >> > should be rebased on top of them. >> >> Unless we're talking about a large merge, I tend to prefer patches. > They >> are much easier to review... >> >> I guess the problem is that we now have a patch in Trond's tree that > conflicts >> with the workqueue patch that's staged for later in Benny's tree. >> I think what I need to do is send Benny a set of patches that starts > with the >> same patch I sent Trond, and follows with one that adds the workqueue. > > Yes. That's the other good feature of patches: the onus of fixing up > conflicts is on you and not on me... :-) > Right. If the required rebase is not trivial I prefer you do it for many reasons, including familiarity with the change and testing the end result. Then, either send the patchset to the list and/or point me to a branch in your tree for me to get the series from Benny > Trond -- 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
