From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) by mx.groups.io with SMTP id smtpd.web11.4997.1599099290321817819 for ; Wed, 02 Sep 2020 19:14:51 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=sjCFSEkP; spf=pass (domain: apple.com, ip: 17.171.2.68, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0832E7jq017896; Wed, 2 Sep 2020 19:14:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=6jTfhOLZ9Tj/piBeJqwk5KZBhMfLM3E/9lxpLXTmQf4=; b=sjCFSEkPKl3WGspyQrlIhOancXGVlKiTiTqZa2irwagF6vscCyrzQauBzOAox71epiRC iKClJaaTHE8C9zYb31b59QDfgAXTobKVkcFnfUBMY8oVUaic6ZF0YAuWLCjytH5l6VZB bUoXv/Zdn07vlkLCodo1b8ONa6bSxjgWRIzSvjczBdSlPMlm8EI1uVvTqhyYtCNJ3SZa tVdDfpT8vRBo/YNTDASsP6Dd7T3lTd3SN7U8yGA9FQkQLHp7MPy2uQGHoUUVOYzqLO7k SBkkYYAo6zGZuWiLAQVlpKWHfayD4l0rj+5oX+rLBd5DJcd3a9pGOjEQ04xbz4Dd7+lt 2Q== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 337kptsd5j-12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 02 Sep 2020 19:14:48 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QG200PFC8WNTB80@rn-mailsvcp-mta-lapp01.rno.apple.com>; Wed, 02 Sep 2020 19:14:47 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QG200Q008JNMQ00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 02 Sep 2020 19:14:47 -0700 (PDT) X-Va-A: X-Va-T-CD: 181541fac3c8f7ce88a2d5f9ee278133 X-Va-E-CD: 28a3b6bbba5087b2256ef43234fe5a54 X-Va-R-CD: 6e35a46220ad25296638c2bb6963dfc2 X-Va-CD: 0 X-Va-ID: d245e424-eef1-4d4b-825a-8cdbde1fbb7a X-V-A: X-V-T-CD: 181541fac3c8f7ce88a2d5f9ee278133 X-V-E-CD: 28a3b6bbba5087b2256ef43234fe5a54 X-V-R-CD: 6e35a46220ad25296638c2bb6963dfc2 X-V-CD: 0 X-V-ID: ca95ad9f-f9a0-429b-b57f-566987107a20 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-09-02_17:2020-09-02,2020-09-02 signatures=0 Received: from [17.235.9.242] (unknown [17.235.9.242]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QG200OCH8WKMZ00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 02 Sep 2020 19:14:46 -0700 (PDT) From: "Andrew Fish" Message-id: MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [edk2-devel] Basetools as a pip module Date: Wed, 02 Sep 2020 19:14:44 -0700 In-reply-to: Cc: Laszlo Ersek , edk2-devel-groups-io , rfc@edk2.groups.io To: Matthew Carlson References: <4C114D94-5320-4825-9400-1044FC5FA9AB@apple.com> <43a4bb4e-8ff1-5b9b-cfc3-22a16dd440db@redhat.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-09-02_17:2020-09-02,2020-09-02 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_48A14207-89D1-4ABF-875D-28F85F3EB272" --Apple-Mail=_48A14207-89D1-4ABF-875D-28F85F3EB272 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Matthew, I did not meant to imply we should optimize for the current installed = base, I just think it is useful to think about them. I think Lazlo is = pointing out what is best for the project and that should have more = weight than the installed base, but it is always good to think how = things impact different groups.=20 In terms of the UI I was thinking of pointing to the pip install = location vs. your git repo not so much a boolean. I actually don=E2=80=99t= quite understand what EDK_TOOL_PATH actually means if BaseTools is a = pip module. If that is an obsolete concept then we should remove it, and = replace with some kind of statement that the pip installed BaseTools are = being used. Another question if I run build from the command line how = did my path get set? For example my user account has 5 different = versions of edk2 in it how do I configure different versions of = BaseTools? How do I pip multiple versions on to my system? I guess my = repo could have a yml file that points to the version of the tools that = I use, but that seems like a per user, not per repo config? It seems to = me we could have developers that want to contribute to edk2 and work on = their own code base and that could rehire two different Basetool = versions installed on the system, and I think we need a story for that.=20= For the macOS Xcode compiler you can install as many versions as you = want and there is a command line tool to let you set the current version = of Xcode, and to show you the currently select versions. Basically the = tools in the magic location in your path are just redirectors to the = currently selected tools.=20 Thanks, Andrew Fish > On Sep 2, 2020, at 12:06 PM, Matthew Carlson = wrote: >=20 > Andrew: >=20 > I think leveraging the existing edksetup is a great idea. Using the = existing EDK_TOOL_PATH variable could work but it seems clunky. Since = the pip module wouldn't be a path, it seems strange to put a boolean = value in a variable meant to hold a path. I definitely think that the = scripts could print whether they're using the pip modules or the = in-source tools. Since Lazlo suggested that pip will be the default, we = could have the in-source modules notify of the fact that you're using = the in-source modules. An additional feature for the pip module could be = printing the version that they are (since you can use the pip = infrastructure to query the version of a given module within a python = script). Another option would be simply trying the pip module first and = then falling back to the in-source module. There would be a slight speed = penalty (likely around 10ms) but since this would only apply to trim and = build, it should have relatively low impact. >=20 > Lazlo: > Thank you for the excellent summary of the different pieces of the = discussion along with the links. To answer your first point, I think = what a developer does with their pip module is largely up to them. They = could do a virtual environment, they could just do what the requirements = state, or pip install from a checked out basetools.I do think there are = some variables that the virtual environment sets up that would be a good = signal whether you're in a virtual environment or not. I agree with your = approach of basetools development going into the out of edk2 repo and = the importance of making sure package maintainers test and validate = their areas with the new setup. I would personally try to get this early = into the development cycle, (just after this next stable tag this week) = to give the community and developers the most amount of time to get used = to things. A trial period of one release makes sense. >=20 > I also agree that the gateway is important in maintaining cohesion = between the new and the old. Hopefully that's nearing completion.=20 >=20 > Hopefully other stewards will weigh in but otherwise we'll move ahead = with a proposed solution in patches next week. >=20 > -Matthew Carlson >=20 >=20 > On Wed, Sep 2, 2020 at 1:49 AM Laszlo Ersek > wrote: > On 09/02/20 02:49, Andrew Fish via groups.io = wrote: > >=20 > >=20 > >> On Sep 1, 2020, at 4:35 PM, Matthew Carlson = > wrote: > >> > >> Hello all, > >> > >> A recent topic on the RFC mailing list went out and the work on = moving Basetools/Sources/Python to a separate repo has started. See the = RFC conversation here: https://edk2.groups.io/g/rfc/topic/74009714#270 = = > > >> > >> The repo in question is here: = https://github.com/tianocore/edk2-basetools = = > > >> > >> The current plan is shortly after the stable tag is created, a = series of patches will come into edk2 that redirects the build system = into the new python module as well as adds additional documentation. You = can see a sample of this work here: = https://github.com/matthewfcarlson/edk2 = = > as this has a branch that has = the work required to use the basetools pip module. The patches won't = delete the Basetools/Sources/Python folder but will allow users to = select between them. After a certain grace period, the python folder = will be deleted and the pip module will be the de facto way of using = basetools. > >> > >> Three questions need to be answered: > >> > >> 1. After the patches that enable the pip module land, how long = should the grace period be? > >> 2. During the grace period, should basetools commits land in both = places or just in the edk2-basetools directory? > >> 3. How should the user be able to select which basetools to use = (the one in EDK2 or the pip module)? Currently the approach being = considered is a simple environmental variable? One of the key = considerations is transparency since it won't be apparent what is being = used for a particular build without some sort of mechanism to notify the = developer. With two seperate versions of Basetools, it becomes very easy = for the version of basetools you're using to not be the one you expect. > >> > >=20 > > Matthew, > >=20 > > I=E2=80=99ll throw out some current developer centric ideas.=20 > >=20 > > 1) If you `source edksetup.sh` (edksetup.bat) you get the current = behavior, and you add an argument you get the pip flavor? So maybe = `edksetup.bat pip-basetools`? > > 2) We have similar issues to this with env variables and the build = command dumps them out when it runs. Can we use the current = EDK_TOOL_PATH? Or maybe add an extra print to show that the pip module = is being used? >=20 > I've skimmed: >=20 > - the earlier discussion linked above (rooted at = >), >=20 > - the even earlier comments in the "Discussion: Basetools a separate = repo" thread on edk2-devel: >=20 > https://edk2.groups.io/g/devel/message/57482 = > = http://mid.mail-archive.com/734D49CCEBEEF84792F5B80ED585239D5C5019CE@SHSMS= X104.ccr.corp.intel.com = >=20 > If I still understand / remember correctly, the way at least *I* would = use the new feature is the following: >=20 > - set up a new virtual python environment, >=20 > - either install the new pip module "permanently" in the virtual = environment, or else install it in "editable mode" from a git checkout = (but *still* in the virtual environment) >=20 > - build edk2 with the virtual environment active >=20 > That is, for me anyway, the key distinguishing factor would be that = I'd be in a python virtual environment where this particular python = module existed / were installed. >=20 > Does this answer question (3)? Because, in my case anyway, I wouldn't = have to be *notified* about using the separate basetools repo vs. using = the one resident in edk2 -- instead, I'd have to *activate* the separate = basetools repo myself, as first step. So if that activation brings some = queriable feature into the environment (sets a new environment variable = or makes a new python package appear in the environment), then I think = it's good enough -- the usual tools that I run then can query these = artifacts. >=20 > In short (I guess): commands should use the in-tree variant, unless I = activate the virtual environment that has the basetools PIP module = installed. >=20 > I think it would be fine to require that, *if* someone intends to = activate such a python virtual environment, *then* they do so *before* = running "edksetup.sh". So "edksetup.sh" could check for the python env = having the external basetools repo / module active. Hopefully that would = be "early enough". >=20 >=20 > Regarding the grace period -- questions (1) and (2): >=20 > - The patches introducing the new feature to edk2 should be posted to = the list. These patches should also add a warning to "edksetup.sh" that = urges the developer to use the out-of-tree basetools repo / PIP module, = in case "edksetup.sh" determines the current choice is the in-tree = variant (that is, the virtual env is inactive, or does not contain the = new PIP module) >=20 > - While the patches are pending approval, BaseTools development is put = on hold (no fixes, no features). >=20 > - For every package (subsystem) listed in Maintainers.txt, in *both* = edk2 *and* edk2-platfomrs, at least one "M" person is required to report = back with a Tested-by, meaning that they built said package successfully = with the new PIP module. >=20 > - When this feedback is complete, the patch is merged, and the new PIP = module becomes the default build system (see the edksetup.sh warning = described above). >=20 > - Optimally, the above (=3D comprehensive testing feedback, and = merging) would occur *early* in the development cycle (just after the = last stable tag). >=20 > - Going forward, bug reports and feature requests are only addressed = in the new (out-of-tree) module. If someone reports that they have to = switch back, *temporarily*, for whatever reason, to the in-tree variant, = and the in-tree variant no longer builds edk2 for them, then such issues = can be resolved on a case-by-case basis, *after* the issue is reported. = Point being, we make the out-of-tree system the new default because of = the comprehensive and strict initial testing requirements (see above); = after which the old system is preserved for a while only as a fallback. = If the fallback proves lacking later on (but still during the grace = period), then the community works to resolve the issue in one of two = ways: either help the issue reporter eliminate their need to use the = fallback in the first place, or backport the subject bugfix/feature to = the fallback. >=20 > - After the *next* stable release (which still contains both the = fallback and the support for the out-of-tree PIP module), the fallback = is removed. >=20 > Ultimately this would make the grace period almost one full = development cycle, in which cycle the new system should be tested = comprehensively, and become the default, near the beginning of the = period. >=20 > This is just my proposal. Some of the other stewards are temporarily = away; I'd suggest waiting for their feedback too. >=20 > To finish up, I would like to highlight something from the earlier = RFC: >=20 > """ > Contribution/Dev Process: > Since this is a separate repo, it will follow a slightly different = contribution and code review process. > 1. Github PR process will be used for contributions and code = review feedback > a. The yet to be released =E2=80=9CTianocore PR archiver=E2=80=9D = will be used to send to a dedicated list for basetools patch review = archive > 2. PRs will only be committed if they keep linear history (no = merge commits) > 3. The PR review must be approved by at least 2 members of the = basetools team (not including the author) > 4. The PR must pass all automated checks > a. Formatting/style > b. Unit tests > c. Code coverage (can=E2=80=99t commit change that would decrease = overall %) > d. DCO enforcement - https://probot.github.io/apps/dco/ = > e. See other python requirements from the Python coding standard > 5. Github Issues will be used for non-security sensitive = bugs/issues/feature requests > """ >=20 > Point (1a) is a pre-requisite for merging the edk2 patches! >=20 > We cannot make the new system the default unless its development = process is integrated with the github-to-email gateway (webhook). >=20 > Thanks! > Laszlo >=20 --Apple-Mail=_48A14207-89D1-4ABF-875D-28F85F3EB272 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Matthew,

I = did not meant to imply we should optimize for the current installed = base, I just think it is useful to think about them. I think Lazlo is = pointing out what is best for the project and that should have more = weight than the installed base, but it is always good to think how = things impact different groups. 

In terms of the UI I was thinking of = pointing to the pip install location vs. your git repo not so much a = boolean. I actually don=E2=80=99t quite understand what EDK_TOOL_PATH = actually means if BaseTools is a pip module. If that is an obsolete = concept then we should remove it, and replace with some kind of = statement that the pip installed BaseTools are being used. Another = question if I run build from the command line how did my path get set? = For example my user account has 5 different versions of edk2 in it how = do I configure different versions of BaseTools? How do I pip multiple = versions on to my system? I guess my repo could have a yml file that = points to the version of the tools that I use, but that seems like a per = user, not per repo config? It seems to me we could have developers that = want to contribute to edk2 and work on their own code base and that = could rehire two different Basetool versions installed on the system, = and I think we need a story for that. 

For the macOS Xcode compiler you can = install as many versions as you want and there is a command line tool to = let you set the current version of Xcode, and to show you the currently = select versions. Basically the tools in the magic location in your path = are just redirectors to the currently selected tools. 

Thanks,

Andrew Fish

On Sep 2, 2020, at 12:06 PM, Matthew Carlson <matthewfcarlson@gmail.com> wrote:

Andrew:

I think = leveraging the existing edksetup is a great idea. Using the existing = EDK_TOOL_PATH variable could work but it seems clunky. Since the pip = module wouldn't be a path, it seems strange to put a boolean value in a = variable meant to hold a path. I definitely think that the scripts could = print whether they're using the pip modules or the in-source tools. = Since Lazlo suggested that pip will be the default, we could have the = in-source modules notify of the fact that you're using the in-source = modules. An additional feature for the pip module could be printing the = version that they are (since you can use the pip infrastructure to query = the version of a given module within a python script). Another option = would be simply trying the pip module first and then falling back to the = in-source module. There would be a slight speed penalty (likely around = 10ms) but since this would only apply to trim and build, it should have = relatively low impact.

Lazlo:
Thank you = for the excellent summary of the different pieces of the discussion = along with the links. To answer your first point, I think what a = developer does with their pip module is largely up to them. They could = do a virtual environment, they could just do what the requirements = state, or pip install from a checked out basetools.I do think there are = some variables that the virtual environment sets up that would be a good = signal whether you're in a virtual environment or not. I agree with your = approach of basetools development going into the out of edk2 repo and = the importance of making sure package maintainers test and validate = their areas with the new setup. I would personally try to get this early = into the development cycle, (just after this next stable tag this week) = to give the community and developers the most amount of time to get used = to things. A trial period of one release makes sense.

I also agree that the = gateway is important in maintaining cohesion between the new and the = old. Hopefully that's nearing completion. 

Hopefully other stewards will weigh in = but otherwise we'll move ahead with a proposed solution in patches next = week.

-Matthew Carlson


On Wed, Sep 2, 2020 at 1:49 AM Laszlo Ersek <lersek@redhat.com> wrote:
On 09/02/20 02:49, Andrew Fish via groups.io wrote:
>
>
>> On Sep 1, 2020, at 4:35 PM, Matthew Carlson <matthewfcarlson@gmail.com> wrote:
>>
>> Hello all,
>>
>> A recent topic on the RFC mailing list went out and the work on = moving Basetools/Sources/Python to a separate repo has started. See the = RFC conversation here: https://edk2.groups.io/g/rfc/topic/74009714#270 <https://edk2.groups.io/g/rfc/topic/74009714#270>
>>
>> The repo in question is here: https://github.com/tianocore/edk2-basetools <https://github.com/tianocore/edk2-basetools>
>>
>> The current plan is shortly after the stable tag is created, a = series of patches will come into edk2 that redirects the build system = into the new python module as well as adds additional documentation. You = can see a sample of this work here: https://github.com/matthewfcarlson/edk2 = <https://github.com/matthewfcarlson/edk2> as this has a = branch that has the work required to use the basetools pip module. The = patches won't delete the Basetools/Sources/Python folder but will allow = users to select between them. After a certain grace period, the python = folder will be deleted and the pip module will be the de facto way of = using basetools.
>>
>> Three questions need to be answered:
>>
>> 1. After the patches that enable the pip module land, how long = should the grace period be?
>> 2. During the grace period, should basetools commits land in = both places or just in the edk2-basetools directory?
>> 3. How should the user be able to select which basetools to use = (the one in EDK2 or the pip module)? Currently the approach being = considered is a simple environmental variable? One of the key = considerations is transparency since it won't be apparent what is being = used for a particular build without some sort of mechanism to notify the = developer. With two seperate versions of Basetools, it becomes very easy = for the version of basetools you're using to not be the one you = expect.
>>
>
> Matthew,
>
> I=E2=80=99ll throw out some current developer centric ideas.
>
> 1) If you `source edksetup.sh` (edksetup.bat) you get the current = behavior, and you add an argument you get the pip flavor? So maybe = `edksetup.bat pip-basetools`?
> 2) We have similar issues to this with env variables and the build = command dumps them out when it runs. Can we use the current = EDK_TOOL_PATH? Or maybe add an extra print to show that the pip module = is being used?

I've skimmed:

- the earlier discussion linked above (rooted at <https://edk2.groups.io/g/rfc/message/270>),

- the even earlier comments in the "Discussion: Basetools a separate = repo" thread on edk2-devel:

  https://edk2.groups.io/g/devel/message/57482
=   http://mid.mail-archive.com/734D49CCEBEEF84792F5B80ED585239D5C5= 019CE@SHSMSX104.ccr.corp.intel.com

If I still understand / remember correctly, the way at least *I* would = use the new feature is the following:

- set up a new virtual python environment,

- either install the new pip module "permanently" in the virtual = environment, or else install it in "editable mode" from a git checkout = (but *still* in the virtual environment)

- build edk2 with the virtual environment active

That is, for me anyway, the key distinguishing factor would be that I'd = be in a python virtual environment where this particular python module = existed / were installed.

Does this answer question (3)? Because, in my case anyway, I wouldn't = have to be *notified* about using the separate basetools repo vs. using = the one resident in edk2 -- instead, I'd have to *activate* the separate = basetools repo myself, as first step. So if that activation brings some = queriable feature into the environment (sets a new environment variable = or makes a new python package appear in the environment), then I think = it's good enough -- the usual tools that I run then can query these = artifacts.

In short (I guess): commands should use the in-tree variant, unless I = activate the virtual environment that has the basetools PIP module = installed.

I think it would be fine to require that, *if* someone intends to = activate such a python virtual environment, *then* they do so *before* = running "edksetup.sh". So "edksetup.sh" could check for the python env = having the external basetools repo / module active. Hopefully that would = be "early enough".


Regarding the grace period -- questions (1) and (2):

- The patches introducing the new feature to edk2 should be posted to = the list. These patches should also add a warning to "edksetup.sh" that = urges the developer to use the out-of-tree basetools repo / PIP module, = in case "edksetup.sh" determines the current choice is the in-tree = variant (that is, the virtual env is inactive, or does not contain the = new PIP module)

- While the patches are pending approval, BaseTools development is put = on hold (no fixes, no features).

- For every package (subsystem) listed in Maintainers.txt, in *both* = edk2 *and* edk2-platfomrs, at least one "M" person is required to report = back with a Tested-by, meaning that they built said package successfully = with the new PIP module.

- When this feedback is complete, the patch is merged, and the new PIP = module becomes the default build system (see the edksetup.sh warning = described above).

- Optimally, the above (=3D comprehensive testing feedback, and merging) = would occur *early* in the development cycle (just after the last stable = tag).

- Going forward, bug reports and feature requests are only addressed in = the new (out-of-tree) module. If someone reports that they have to = switch back, *temporarily*, for whatever reason, to the in-tree variant, = and the in-tree variant no longer builds edk2 for them, then such issues = can be resolved on a case-by-case basis, *after* the issue is reported. = Point being, we make the out-of-tree system the new default because of = the comprehensive and strict initial testing requirements (see above); = after which the old system is preserved for a while only as a fallback. = If the fallback proves lacking later on (but still during the grace = period), then the community works to resolve the issue in one of two = ways: either help the issue reporter eliminate their need to use the = fallback in the first place, or backport the subject bugfix/feature to = the fallback.

- After the *next* stable release (which still contains both the = fallback and the support for the out-of-tree PIP module), the fallback = is removed.

Ultimately this would make the grace period almost one full development = cycle, in which cycle the new system should be tested comprehensively, = and become the default, near the beginning of the period.

This is just my proposal. Some of the other stewards are temporarily = away; I'd suggest waiting for their feedback too.

To finish up, I would like to highlight something from the earlier = RFC:

"""
Contribution/Dev Process:
Since this is a separate repo, it will follow a slightly different = contribution and code review process.
1.      Github PR process will be used for contributions = and code review feedback
a.      The yet to be released =E2=80=9CTianocore PR = archiver=E2=80=9D will be used to send to a dedicated list for basetools = patch review archive
2.      PRs will only be committed if they keep linear = history (no merge commits)
3.      The PR review must be approved by at least 2 = members of the basetools team (not including the author)
4.      The PR must pass all automated checks
a.      Formatting/style
b.      Unit tests
c.      Code coverage (can=E2=80=99t commit change that = would decrease overall %)
d.      DCO enforcement - https://probot.github.io/apps/dco/
e.      See other python requirements from the Python = coding standard
5.      Github Issues will be used for non-security = sensitive bugs/issues/feature requests
"""

Point (1a) is a pre-requisite for merging the edk2 patches!
=
We cannot make the new system the default unless its development process = is integrated with the github-to-email gateway (webhook).

Thanks!
Laszlo


= --Apple-Mail=_48A14207-89D1-4ABF-875D-28F85F3EB272--