From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Fri, 30 Aug 2019 04:50:01 -0700 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 650C9C08E285; Fri, 30 Aug 2019 11:50:00 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (unknown [10.36.118.66]) by smtp.corp.redhat.com (Postfix) with ESMTP id C02009F63; Fri, 30 Aug 2019 11:49:57 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] MdePkg/DxeHstiLib: Added checks to improve error handling. To: "Ni, Ray" , "devel@edk2.groups.io" , Leif Lindholm Cc: "Gao, Liming" , "Cetola, Stephano" , "Kinney, Michael D" , "Jayanth.Raghuram@dell.com" , "'Andrew Fish (afish@apple.com)'" , "Wei.G.Liu@dell.com" References: <31e5cee5c49d4381bfb26a0968c11749@ausx13mps324.AMER.DELL.COM> <4A89E2EF3DFEDB4C8BFDE51014F606A14E4DCA9B@SHSMSX104.ccr.corp.intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E4DD7DA@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5C2A1B73@SHSMSX104.ccr.corp.intel.com> <20190829094942.GN29255@bivouac.eciton.net> <734D49CCEBEEF84792F5B80ED585239D5C2A36C1@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: <9af274fa-3d1f-073d-da8e-8cb86e42fd5e@redhat.com> Date: Fri, 30 Aug 2019 13:49:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C2A36C1@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 30 Aug 2019 11:50:00 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/29/19 19:02, Ni, Ray wrote: > > >> -----Original Message----- >> From: devel@edk2.groups.io On Behalf Of Laszlo Ersek >> Sent: Thursday, August 29, 2019 7:24 AM >> To: Leif Lindholm ; Ni, Ray >> Cc: Gao, Liming ; Cetola, Stephano ; Kinney, Michael D >> ; Jayanth.Raghuram@dell.com; 'Andrew Fish (afish@apple.com)' ; >> Wei.G.Liu@dell.com; devel@edk2.groups.io >> Subject: Re: [edk2-devel] [PATCH] MdePkg/DxeHstiLib: Added checks to improve error handling. >> - Doesn't work for patch series, only for single patches. > Laszlo, > Do you mean attachment is not allowed for a series of patch? That's correct; I mean that. > Why? A mail can carry multiple attachments. That makes the patch series easy to fetch in my opinion from Outlook. The goal is to enable fine-grained, email based review comments. Meaning, a reviewer responds to the original email, whereby the original patch is quoted in full in the response. Then the reviewer inserts comments near the code locations in the patch that need updates. This approach works perfectly when the original email was sent with git-send-email. The approach works tolerably (as an exception to our workflow) when the original email was sent manually, with a single patch pasted or attached. Because, in this case, the review comments can still be made context-sensitively, and the threading structure will be sane. The approach does not work at all when a single email carries multiple patches. Quoting becomes a mess, review comments are a lot more difficult to associate with the targeted patch within the series, and so on. If the contribution is a patch series (i.e., not a single patch), and the submitter is unable to use "git-send-email", then the submitter is responsible for manually establishing the exact same shallow thread structure that git-send-email would. Specifically, the submitter first needs to send a cover letter email, then they need to send each patch individually, with numbered subjects, in direct response to the cover letter email. They can paste or attach one patch per email, until the full series is posted. The email thread must reflect the git commits so that a specific git commit has a matching "entry point" into the mailing list discussion -- i.e., a reviewer interested in a given git commit can find the precisely matching email, and the related *sub*-thread that discusses that particular commit. Email is not merely a dumb carrier for patches where it's OK to drop a single patch-bomb email (let alone a ZIP file) on reviewers. A well-structured email thread is vital to careful review, and for the long-term archival of the discussion. Thanks, Laszlo