From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [v10][PATCH 11/16] tools/libxl: detect and avoid conflicts with RDM Date: Wed, 22 Jul 2015 11:51:16 +0100 Message-ID: <1437562276.12884.26.camel@citrix.com> References: <1437373023-14884-1-git-send-email-tiejun.chen@intel.com> <1437373023-14884-12-git-send-email-tiejun.chen@intel.com> <21932.63595.566823.211293@mariner.uk.xensource.com> <21934.8684.318670.874156@mariner.uk.xensource.com> <55AE272A.4020306@intel.com> <21934.10490.615041.203428@mariner.uk.xensource.com> <55AE2BB1.9030604@intel.com> <21934.11410.844215.554291@mariner.uk.xensource.com> <55AE30D4.8000009@intel.com> <21934.15393.528332.534956@mariner.uk.xensource.com> <55AE492D.7080204@intel.com> <21934.24721.304399.773580@mariner.uk.xensource.com> <55AE6871.6070903@intel.com> <21934.27603.498330.185762@mariner.uk.xensource.com> <55AEE4E6.5030508@intel.com> <1437554603.407.36.camel@citrix.com> <55AF6000.7010108@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55AF6000.7010108@intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Chen, Tiejun" , Ian Jackson Cc: xen-devel@lists.xen.org, Wei Liu , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Wed, 2015-07-22 at 17:18 +0800, Chen, Tiejun wrote: > Thanks for your clarification to me. > > > The solution to this is to be systematic in how you handle the > > email > > based review of a series, not to add a further to the reviewer by > > using > > IRC as well. > > > > For example, here is how I handle review of a series I am working > > on: > > > > I keep all the replies to a series I'm working on marked unread. > > When I > > come to rework the series I take the first reply to the first patch > > and > > start a draft reply to it quoting the entire review. > > > > I then go through the comments one by one and either: > > > > * make the _complete_ code change, including adding the > > "Changes > > in vN" bit to the commit log and delete that comment from > > the > > reply > > Are you saying this case of resending this particular patch online? No, I am talking about making the change in my local git tree. Only once I have addressed _all_ of the review of the whole series would I resent a complete new version of the series for further review. > > > or > > * write a reply in my draft to that particular comment which > > does > > one or more of: > > > > * Explain that I don't understand the suggestion, > > probably asking questions to try and clarify what > > was > > being asked for. > > Yes, in this case we're arguing, I was really trying to send a sample > of > this code fragment to ask this before I sent out the complete change. I was not talking about any specific case here. > > At the end of this process _every_ bit of review feedback is addressed > > either by making the requested change or by responding explaining the > > reason why the change hasn't been made. This is absolutely crucial. You > > should never silently ignore a piece of review, even if you don't > > I should double check each line but sometimes this doesn't mean I can > > understand everything correctly to do right thing as you expect. But > this is really not what I intend to do. I have outlined my strategy for dealing with review which helps avoid/minimise the error rate (i.e. failing to address comments) when dealing with reviews. I hope it will be helpful for you in forming your own strategy. Ian.