From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web10.10120.1589536032719042405 for ; Fri, 15 May 2020 02:47:13 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3B88F2F; Fri, 15 May 2020 02:47:11 -0700 (PDT) Received: from [192.168.1.81] (unknown [10.37.8.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 976253F71E; Fri, 15 May 2020 02:47:06 -0700 (PDT) Subject: Re: [edk2-devel] Where to put the bhyve code in the edk2 repo: BhyvePkg, or under OvmfPkg? To: Laszlo Ersek , Rebecca Cran , devel@edk2.groups.io Cc: michael.d.kinney@intel.com, Andrew Fish , Leif Lindholm , "Justen, Jordan L" , Peter Grehan References: <58b768dc-cad7-08e5-2fe6-ba3e81002097@redhat.com> <32735AC0-2354-4ADB-A4D5-A3D93DA00385@bsdio.com> <56efcbf5-2fe8-4620-a98c-7b2bb60f0ceb@redhat.com> From: "Ard Biesheuvel" Message-ID: <4abae9ee-adfb-84e6-67d2-ce31898e0bc1@arm.com> Date: Fri, 15 May 2020 11:47:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <56efcbf5-2fe8-4620-a98c-7b2bb60f0ceb@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 5/15/20 11:42 AM, Laszlo Ersek wrote: > On 05/14/20 18:20, Rebecca Cran wrote: >> >>> On May 14, 2020, at 4:24 AM, Laszlo Ersek wrote: >>> >>> - The community not having any human resources permanently dedicated to >>> bhyve regressions (testing, review, and post factum fixing) is fine, as >>> long as the bhyve stakeholders can live with a matching frequency of >>> regressions. >> >> Yes, I believe that would be acceptable. >> Has there been a decision on the directory structure yet, or is that likely to be something that will need resolved at the next Stewards Meeting? > > Based on the discussion thus far, I'd suggest > "OvmfPkg/SecondClass/Bhyve". If you have the time, just go ahead and > submit the series like that, and wait for review. > > If you'd first like to be sure that everyone's OK with this pathname, > then please wait for more feedback in this thread. > Please no. SecondClass/ implies some kind of hall of shame, which is not a fair characterization. I think it would be better to simply host this code under OvmfPkg/Bhyve, and put some annotation in Maintainers.txt to document that regressions that only affect Bhyve are not treated with the same level of urgency as ones that affect OVMF for QEMU.