Re: [edk2-devel] EDK II Stable Tag release edk2-stable201905 completed

["Laszlo Ersek" <lersek@redhat.com>]

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
<https://github.com/google/boringssl>, 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 <https://github.com/google/boringssl> 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