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; Thu, 29 Aug 2019 07:24:16 -0700 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EFACD1801585; Thu, 29 Aug 2019 14:24:15 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-174.ams2.redhat.com [10.36.117.174]) by smtp.corp.redhat.com (Postfix) with ESMTP id EA2FD1001B1A; Thu, 29 Aug 2019 14:24:13 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] MdePkg/DxeHstiLib: Added checks to improve error handling. 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" 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> From: "Laszlo Ersek" Message-ID: Date: Thu, 29 Aug 2019 16:24:12 +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: <20190829094942.GN29255@bivouac.eciton.net> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.63]); Thu, 29 Aug 2019 14:24:16 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/29/19 11:49, Leif Lindholm wrote: > On Wed, Aug 28, 2019 at 05:33:28PM +0000, Ni, Ray wrote: >> With the existence of mail attachments capability in new groups.io >> system, can we accept such kind of patch submission? Or any side >> effect you see if allowing mail attachments? > > Traditionally, the reason for not wanting patches as attachments is > that it complicates doing inline code review as part of the email. > > If the mail system (let's take a wild guess, Outlook/Exchange?) > doesn't corrupt the text *too* badly, I don't have an issue with the > patch being sent in the message body *and* being attached so it could > actually be applied. > > Alternatively, one could put the patch in the message body and a link > to the patch in a public repo where it can be obtained. I agree (with either alterative), as follows: - The patch must be pasted manually in the message body, or it must be attached. - The patch must be published in a personal git repo, and the email posting needs to reference that repo / branch. - This is only acceptable as an exception to the workflow, and not as the norm. (As long as our official contribution workflow is mailing list based.) - Doesn't work for patch series, only for single patches. - v2, v3 and so iterations must use separate topic branches in the submitter's personal repository. Non-fast-forward pushes to already posted -- hence publicly referenced -- branches are not acceptable. Effectively, once v(n) is posted, the submitter should consider the matching topic branch in their own repo read-only. - The edk2 package maintainer that ends up pushing the patch is responsible for ensuring that the patch taken with "git fetch" for integration is identical to the patch that was manually pasted by the submitter. The idea is that mailing list based review work as always, plus that the patch that goes in ultimately be the same patch that got reviewed on the list. Thanks Laszlo