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; Wed, 12 Jun 2019 02:37:58 -0700 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 224FF30872FD; Wed, 12 Jun 2019 09:37:53 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-191.ams2.redhat.com [10.36.117.191]) by smtp.corp.redhat.com (Postfix) with ESMTP id B626046; Wed, 12 Jun 2019 09:37:50 +0000 (UTC) Subject: Re: [edk2-devel] EDK II Stable Tag release edk2-stable201905 completed To: Leif Lindholm Cc: devel@edk2.groups.io, "Gao, Liming" , "Kinney, Michael D" , "afish@apple.com" References: <4A89E2EF3DFEDB4C8BFDE51014F606A14E46CD3D@SHSMSX104.ccr.corp.intel.com> <7606aa6e.d162.16b40a3cb45.Coremail.sssky307@163.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E46DF7E@SHSMSX104.ccr.corp.intel.com> <20190610140014.botd5fxrrrrus4a5@bivouac.eciton.net> <20190611103007.fwnbpiympnofpy4x@bivouac.eciton.net> <6bbebdd6-a90a-ca83-b0af-105afa70a88c@redhat.com> <20190611160821.t7kqcdoc33nukgut@bivouac.eciton.net> <625afe99-fcd0-7a08-eb63-7b9e8a64b44e@redhat.com> <20190612092105.y6ig6rsaybqadunw@bivouac.eciton.net> From: "Laszlo Ersek" Message-ID: <4e3db1e1-3e22-406e-8c9f-187727ed4751@redhat.com> Date: Wed, 12 Jun 2019 11:37:49 +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: <20190612092105.y6ig6rsaybqadunw@bivouac.eciton.net> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Wed, 12 Jun 2019 09:37:57 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/12/19 11:21, Leif Lindholm wrote: > On Wed, Jun 12, 2019 at 10:18:24AM +0200, Laszlo Ersek wrote: >>> In this instance, we explicitly don't care about the submodule for >>> that other project (and I really hope this is the norm) - so we >>> shouldn't be documenting steps that rely on that additional >>> submodule existing. >> >> Yes; this is why I suggested dropping "--recursive" from the >> instructions. As far as I remember, it was meant as a convenience for >> users cloning the edk2 repo from zero. > > But we've never actually relied on that behaviour, so it's not so much > convenience as cargo culting. > >>> This is why I am referring to anything other than a central definition >>> of the relationship between edk2 and its submodules as a workaround. I >>> am not suggesting any shortcomings in the technical aspect. >> >> Can you provide an example definition then? I'm having trouble imagining >> one. > > Laszlo, I think you've misunderstood me somewhere. That's for certain. :) > What I am saying is: > - We should have a policy (i.e., a section in toplevel Readme.md) > regarding submodules. > - That policy *should* include the requirement to not permit > submodules requiring submodules for our purposes. > - That policy should include the steps required to get the edk2 > repository to a buildable state. > - Nothing related to submodules should be documented anywhere else > in the tree. Sure, OpenSSL-HOWTO.txt can still be there, but > the section "HOW to Install OpenSSL for UEFI Building" should go. Got it now. Good idea. Thanks! Laszlo