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, 08 May 2019 02:55:34 -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 DB74B3097020; Wed, 8 May 2019 09:55:33 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-255.rdu2.redhat.com [10.10.120.255]) by smtp.corp.redhat.com (Postfix) with ESMTP id 08BA110027C2; Wed, 8 May 2019 09:55:32 +0000 (UTC) Subject: Re: [edk2-devel] RFC for Edk2-Library To: devel@edk2.groups.io, sean.brogan@microsoft.com References: <24030.1557264917803034398@groups.io> From: "Laszlo Ersek" Message-ID: Date: Wed, 8 May 2019 11:55:31 +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: <24030.1557264917803034398@groups.io> 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.43]); Wed, 08 May 2019 09:55:33 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 05/07/19 23:35, Sean via Groups.Io wrote: > RFC Edk2-Library creation > > Create a new tianocore owned repository to host a python library > package in support of UEFI development. This package will allow easy > sharing of python library code to facilitate reuse. Inclusion of this > package and dependency management should be managed using Pip/Pypi. To > start this is a supplemental package and is not required to be used > for edk2 builds. [1] > Examples of content here > > * Edk2 file type parsing > * UEFI structure encode/decode in python > * Packaging tools (Capsules generation, signing, INF gen, Cat gen) > * TPM support code > * Potentially move content from basetools/source/python/common/* [2] > * No command line tools/interface > > Maintainers > > * Sean Brogan > * Bret Barkelew > * Placeholder for existing maintainer from the basetools > > License > > * BSD + Patent (edk2 aligned) > > Contribution process and issue tracking > > * Follow Github PR process for contributions and issue tracking > * Contributor forks repo in github > * Contributor creates branch for work > * Contributor updates release notes to indicate change (if necessary) > * Contributor submits PR to master branch of tianocore/Edk2-Library > repo > * Review feedback is given in PR > * Python Tests are run on the repo (new contributions need unit tests) > * Python Style (flake8) must pass > * All review feedback must be completed, maintainers approved, and > tests run successfully before PR is *squash merged* into master The sentences [1] "To start this is a supplemental package and is not required to be used for edk2 builds." [2] "Potentially move content from basetools/source/python/common/*" foreshadow that such a code movement might happen down the road, and the external package could become a requirement for building edk2. That step would mean the following: (a) Edk2 would not remain buildable from a single command git clone --recurse-submodules Building edk2 would require GNU/Linux users to start tracking packages with "pip", which is independent of any given distro's own package management, and may cause conflicts if not used carefully: https://developer.fedoraproject.org/tech/languages/python/pypi-installation.html This requirement on "pip" would only go away once the external python dependencies were packaged for at least the larger GNU/Linux distros. (b) Edk2 users running into build problems related to the external python dependencies would have to contribute through a github-only workflow. That's not a deal-breaker per se -- if we want to contribute to other edk2 dependencies, such as OpenSSL or nasm, we also have to conform to their specific development models, clearly. However, "squash merge" is a catastrophically bad development model, and I'd object to introducing a new edk2 build dependency that followed that model. (There are other issues with the GitHub.com development workflow, as discussed elsewhere, but "squash merge" takes the cake.) Problem (a) would be solvable in the long term (through collaboration with distro maintainers, i.e. downstream packaging), but problem (b) would not be. Thus I'm fine with the proposal, in its current form, only if the new package is 100% an addition on top of edk2, even in the long term, and not in any part intended as a future replacement for current edk2 functionality. Thanks, Laszlo