From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2 To: Ard Biesheuvel ,devel@edk2.groups.io From: "Sean" X-Originating-Location: Redmond, Washington, US (50.35.74.15) X-Originating-Platform: Windows Chrome 82 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Tue, 10 Mar 2020 12:10:34 -0700 References: In-Reply-To: Message-ID: <29466.1583867434210258945@groups.io> Content-Type: multipart/alternative; boundary="t3gxS6sFdJjqpL2LuFuj" --t3gxS6sFdJjqpL2LuFuj Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 10, 2020 at 10:54 AM, Ard Biesheuvel wrote: >=20 > This means we can reasonably require any contributor not to regress on > those platforms, given how they have full access to it, and this is > actually where i would like us to take the next step when it comes to > ci automation, i.e., automatically flag PRs that break the boot on a > selected set of qemu based configs. I appreciate the viewpoint but I don't think edk2 has "required" this yet = and I would push back on that if it was brought up for community discussion= .=C2=A0 As you know I believe contributing to edk2 is much too hard already= , and filled with custom edk2 workflows, and this one would only make it mo= re of a burden to contribute. I do however agree that if this is important to the edk2 community, system= s/automation should be setup to run this type of thing.=C2=A0 If that happe= ns, i don't think it is much harder to do it for multi-repo than single rep= o and if done right for multi-repo then other platforms can opt in as well = and the efforts to build this infrastructure will scale well beyond a singl= e virtual platform. Thanks Sean --t3gxS6sFdJjqpL2LuFuj Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 10, 2020 at 10:54 AM, Ard Biesheuvel wrote:
This means we can reasonably require any contributor not to re= gress on
those platforms, given how they have full access to it, and t= his is
actually where i would like us to take the next step when it co= mes to
ci automation, i.e., automatically flag PRs that break the boot= on a
selected set of qemu based configs.
I appreciate the viewpoint but I don't think edk2 has "required" this yet = and I would push back on that if it was brought up for community discussion= .  As you know I believe contributing to edk2 is much too hard already= , and filled with custom edk2 workflows, and this one would only make it mo= re of a burden to contribute.  

I do however agree tha= t if this is important to the edk2 community, systems/automation should be = setup to run this type of thing.  If that happens, i don't think it is= much harder to do it for multi-repo than single repo and if done right for= multi-repo then other platforms can opt in as well and the efforts to buil= d this infrastructure will scale well beyond a single virtual platform.

Thanks
Sean --t3gxS6sFdJjqpL2LuFuj--