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 01:18:27 -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 28D8888304; Wed, 12 Jun 2019 08:18:27 +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 678DE1001B0A; Wed, 12 Jun 2019 08:18:25 +0000 (UTC) Subject: Re: [edk2-devel] EDK II Stable Tag release edk2-stable201905 completed To: Leif Lindholm Cc: devel@edk2.groups.io, "Gao, Liming" , "sssky307@163.com" , "'announce@edk2.groups.io'" , "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> From: "Laszlo Ersek" Message-ID: <625afe99-fcd0-7a08-eb63-7b9e8a64b44e@redhat.com> Date: Wed, 12 Jun 2019 10:18:24 +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: <20190611160821.t7kqcdoc33nukgut@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.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 12 Jun 2019 08:18:27 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/11/19 18:08, Leif Lindholm wrote: > On Tue, Jun 11, 2019 at 05:46:37PM +0200, Laszlo Ersek wrote: >>> The instructions have spread to many other places (build instructions >>> in wiki and edk2-platforms Readme.md being two of them). >>> That's not to say we shouldn't change it, but that we need to go >>> through and update those places too. >>> >>> And frankly, if we've accepted the need to support submodules, we >>> need to document how edk2 interacts with submodules, not how each >>> individual submodule interacts with edk2 - so the git instructions in >>> OpenSSL-HOWTO.txt should probably be deleted. >>> >>> This might be a good topic to bring to the next design meeting. >>> >>> Presumably the above will be a useful workaround for the original >>> reporter in the meantime. >> >> To be clear -- the problem *exists* only because the original reporter >> is stuck behind a restrictive firewall. There is nothing *technically* >> wrong with the current instructions in "OpenSSL-HOWTO.txt". There is >> nothing particular in how "edk2 interacts with submodules". We're >> discussing workarounds for a political problem. > > At this point in time we are discussing a workaround for a political > problem. But relying on submodules means relinquishing elements of > control and consistency (if github goes down, we're consistently > down). > > 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. > Whether its inaccessibility is for political (not > just this one, but "oh, someone told me there was pirated things on > that host"), technical ("server went down") or financial ("where is me > domain, me noggin' noggin' domain, it's all gone for beer and > tobacco") reasons. > > (Why yes, I may be going slightly loopy from too much python.) > > 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. Or do you have QEMU in mind, as an example? AIUI, the QEMU project has server-side jobs that continuously mirror all submodule repositories from their primary locations to the QEMU git server. And then submodule URLs in the main QEMU tree (the "superproject") point to the mirrored subprojects on "git.qemu.org". This makes sure all submodules can be cloned as long as QEMU itself can be cloned. In edk2, the direct submodules (OpenSSL and SoftFloat) are both on github, same as edk2 itself. OpenSSL seems to have three submodules, "pyca-cryptography" (on github), "krb5" (ditto), and "boringssl" (on "googlesource.com"). "boringssl" has a mirror at , but: - in order to change the URL in OpenSSL, we'd either have to convince the OpenSSL developers to reference the github mirror rather than the central boringssl repo, or we'd have to diverge from OpenSSL upstream in our submodule (with a commit that updates the URL) - we *really* don't need boringssl: - Readme.md at states as much up-front ("it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it") - In OpenSSL, the boringssl submodule was introduced in commit ab29eca645cd ("Run BoringSSL tests on Travis", 2016-11-24). It looks completely useless for superprojects (i.e. for communities that don't actively develop OpenSSL itself). In short I don't see how we can define a uniform / blanket relationship between edk2 and all of its sub-sub-modules. We could provide a list that discussed each case separately. And this list could change every time we moved forward to a new OpenSSL (or other direct submodule) release. I'm sorry if this is just wild speculation but I really don't understand what you have in mind, for the definition. Can you please give an example? Thanks Laszlo