From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v10][PATCH 11/16] tools/libxl: detect and avoid conflicts with RDM Date: Wed, 22 Jul 2015 17:18:56 +0800 Message-ID: <55AF6000.7010108@intel.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1437554603.407.36.camel@citrix.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: Ian Campbell , Ian Jackson Cc: xen-devel@lists.xen.org, Wei Liu , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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? > 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. > * Explain, with reasons, why I disagree with the > suggestion > * Explain, with reasons, why I only implemented part of > the suggestion. > > Only then do I move on to the next comment in that mail and repeat. At > the end I've either deleted all the comments from my draft (because > I've fully implemented everything) so the draft can be discarded or I > have an email to send explaining what I've not done and why. Only now > do I mark the original review email as read. > > Then I move on to the next reply to that thread in my mail box and > repeat until I have been through every mail in the thread and addressed > _all_ of the comments. > > 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. Thanks Tiejun > understand it or disagree with it, always reply and explain why you > haven't. > > If the review was particularly long or complex I will then do a second > pass through the review comments and check that every comment is either > mentioned in a "Changes in vN" changelog comment or I have replied to > it. > > I do all of that before posting the next version. IMHO until a > contributor has shown they are diligent about addressing review > comments they should _never_ send out a series which only has review > partially addressed. > > The presence of an IRC channel in no way changes the requirement to be > systematic and thorough when dealing with email review. > > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >