From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by mx.groups.io with SMTP id smtpd.web10.27994.1583635208055497386 for ; Sat, 07 Mar 2020 18:40:08 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: bsdio.com, ip: 166.70.13.233, mailfrom: rebecca@bsdio.com) Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jAlrK-00074o-MT; Sat, 07 Mar 2020 19:40:07 -0700 Received: from mta1.zcs.xmission.com ([166.70.13.65]) by in02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1jAlrK-00071p-4R; Sat, 07 Mar 2020 19:40:06 -0700 Received: from localhost (localhost [127.0.0.1]) by mta1.zcs.xmission.com (Postfix) with ESMTP id C15C71C401A; Sat, 7 Mar 2020 19:40:05 -0700 (MST) X-Amavis-Modified: Mail body modified (using disclaimer) - mta1.zcs.xmission.com Received: from mta1.zcs.xmission.com ([127.0.0.1]) by localhost (mta1.zcs.xmission.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tTyIKEeyjBP4; Sat, 7 Mar 2020 19:40:05 -0700 (MST) Received: from [10.0.10.120] (muon.bluestop.org [65.103.231.193]) (Authenticated sender: rebecca@bsdio.com) by mta1.zcs.xmission.com (Postfix) with ESMTPSA id C6CE21C400D; Sat, 7 Mar 2020 19:40:04 -0700 (MST) To: devel@edk2.groups.io, ard.biesheuvel@linaro.org, Laszlo Ersek Cc: "Yao, Jiewen" , "Justen, Jordan L" References: <15F9E16A0219E7B7.19404@groups.io> <74D8A39837DF1E4DA445A8C0B3885C503F972D92@shsmsx102.ccr.corp.intel.com> From: "Rebecca Cran" Message-ID: <4ce149a1-e3a7-3ba1-8efd-ecb36252b4df@bsdio.com> Date: Sat, 7 Mar 2020 19:40:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: X-XM-SPF: eid=1jAlrK-00071p-4R;;;mid=<4ce149a1-e3a7-3ba1-8efd-ecb36252b4df@bsdio.com>;;;hst=in02.mta.xmission.com;;;ip=166.70.13.65;;;frm=rebecca@bsdio.com;;;spf=pass X-SA-Exim-Connect-IP: 166.70.13.65 X-SA-Exim-Mail-From: rebecca@bsdio.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa02.xmission.com X-Spam-Level: * X-Spam-Status: No, score=1.6 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_XMDrugObfuBody_12, TooManyTo_001,TooManyTo_002 autolearn=disabled version=3.4.2 X-Spam-Virus: No X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4999] * 0.3 TooManyTo_001 Multiple "To" Header Recipients 2x (uncommon) * 0.5 TooManyTo_002 Multiple "To" Header Recipients 3x (uncommon) * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa02 1397; IP=ok Body=1 Fuz1=1] [Fuz2=1] * 1.0 T_XMDrugObfuBody_12 obfuscated drug references X-Spam-DCC: XMission; sa02 1397; IP=ok Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;devel@edk2.groups.io, ard.biesheuvel@linaro.org, Laszlo Ersek X-Spam-Relay-Country: X-Spam-Timing: total 300 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.6 (0.8%), b_tie_ro: 1.96 (0.7%), parse: 0.76 (0.3%), extract_message_metadata: 2.8 (0.9%), get_uri_detail_list: 0.37 (0.1%), tests_pri_-1000: 2.1 (0.7%), tests_pri_-950: 1.02 (0.3%), tests_pri_-900: 0.83 (0.3%), tests_pri_-90: 15 (5.0%), check_bayes: 14 (4.6%), b_tokenize: 4.0 (1.3%), b_tok_get_all: 5 (1.7%), b_comp_prob: 1.32 (0.4%), b_tok_touch_all: 2.0 (0.7%), b_finish: 0.47 (0.2%), tests_pri_0: 266 (88.7%), check_dkim_signature: 0.59 (0.2%), check_dkim_adsp: 101 (33.7%), poll_dns_idle: 93 (31.1%), tests_pri_10: 1.70 (0.6%), tests_pri_500: 5 (1.8%), rewrite_mail: 0.00 (0.0%) Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2 X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US On 3/7/2020 12:52 AM, Ard Biesheuvel wrote: > Yes, keeping platforms in sync with the core is more painful than it > should be. If we move all platforms out of the core, what are we going > to do for validation? Sure, we'll get a nice tickbox from Azure that > all the semicolons line up nicely, but being able to build something > that can be tested on actual hardware is essential IMO. Talking of which, it would be nice if we could get that sort of validation into the CI builds. I'm hoping somebody's already working on that, since it was mentioned during the initial RFC process? -- Rebecca Cran