From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web12.12393.1589547098687222924 for ; Fri, 15 May 2020 05:51:39 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=GAhmxNJt; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589547097; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=u2o0UHckoeNF6yXLueWmU9isW/srR7q8RlO3A3ZLI9I=; b=GAhmxNJtHdgFV4CxszdQJL6nIdWIeyuvlRRSA7/z20IXEjDShS9LsxEtssNAl5dNUZ3Lay UiYhvIKj8U8GWzs70QO5xXalSnwaSuYGkOhTLUCVM5I5ppZVc61MTojvhZNZFwrvZwVwgM gPbUhUX1b6mGlgX5eQNpCpbLu6wfxG4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-401-y4qvsFB4M_eknJDq1gfyew-1; Fri, 15 May 2020 08:51:33 -0400 X-MC-Unique: y4qvsFB4M_eknJDq1gfyew-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0EABCEC1A0; Fri, 15 May 2020 12:51:32 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-220.ams2.redhat.com [10.36.113.220]) by smtp.corp.redhat.com (Postfix) with ESMTP id 395CF5D714; Fri, 15 May 2020 12:51:29 +0000 (UTC) Subject: Re: [edk2-devel] Where to put the bhyve code in the edk2 repo: BhyvePkg, or under OvmfPkg? To: Ard Biesheuvel , 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> <4abae9ee-adfb-84e6-67d2-ce31898e0bc1@arm.com> From: "Laszlo Ersek" Message-ID: Date: Fri, 15 May 2020 14:51:28 +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: <4abae9ee-adfb-84e6-67d2-ce31898e0bc1@arm.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 05/15/20 11:47, Ard Biesheuvel wrote: > 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. OK. I didn't mean to put bhyve in a "pillory" (I agree it would be unfair), I just couldn't find better words for reflecting the separation you asked for. > I think it would be better to simply host this code under OvmfPkg/Bhyve, OK! > 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. How about "S: Odd Fixes"? From: S: Status, one of the following: Supported: Someone is actually paid to look after this. Maintained: Someone actually looks after it. Odd Fixes: It has a maintainer but they don't have time to do much other than throw the odd patch in. See below. Orphan: No current maintainer [but maybe you could take the role as you write your new code]. Obsolete: Old code. Something tagged obsolete generally means it has been replaced by a better system and you should be using that. Thanks Laszlo