From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web12.10012.1589535592027312447 for ; Fri, 15 May 2020 02:39:52 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fTw9PAlp; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589535590; 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=09iDa7rPRXt7AJRZ72nJTcswvzrYcTe8NPiyA3MP3uw=; b=fTw9PAlpiQ/JXNa3QXuVzQO+qHUt/Muv9puGmPIu1BCkO1BPbCf0yLaOsB+//pxx9HRZx5 1h9zNPZAPtyaQCaGcop+RsEETXC40OOwY0arpTbZ1Pw2TkvROi+//HOYKOSYAZKZUm5Rzf 1bsb1WcLZ1lOIOueOYqsWE/lppK44lw= 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-142-fGfcJTTWNCqR8Jyqg8Q5dg-1; Fri, 15 May 2020 05:39:48 -0400 X-MC-Unique: fGfcJTTWNCqR8Jyqg8Q5dg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4BC41EC1A2; Fri, 15 May 2020 09:39:47 +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 51A4D5C1D6; Fri, 15 May 2020 09:39:45 +0000 (UTC) Subject: Re: [edk2-devel] Where to put the bhyve code in the edk2 repo: BhyvePkg, or under OvmfPkg? To: Sean Brogan , devel@edk2.groups.io, rebecca@bsdio.com Cc: michael.d.kinney@intel.com, Ard Biesheuvel , Andrew Fish , Leif Lindholm , "Justen, Jordan L" , Peter Grehan References: <58b768dc-cad7-08e5-2fe6-ba3e81002097@redhat.com> <32735AC0-2354-4ADB-A4D5-A3D93DA00385@bsdio.com> From: "Laszlo Ersek" Message-ID: Date: Fri, 15 May 2020 11:39:44 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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/14/20 19:48, Sean Brogan wrote: > Adding another platform to a core repository that might or might not > work at any given time is a burden to all core contributors and doesn't > bring value to the core project. Platforms that depend on edk2, but are not inside edk2, are near guaranteed to break when core edk2 changes occur. Such external dependencies are impossible to locate with "git grep"; you can't run a git-grep on "all projects in the universe that consume edk2". Even if you manage to identify some high-profile out-of-tree platforms (by sheer diligence, or by those platforms' own CI systems -- doesn't matter), you are effectively prevented from adjusting them in the *right patch order*, as you cannot cover multiple repositories in a single patch series. This is already causing *massive* and everyday pain with edk2-platforms; contributions that would normally take the form of a run-of-the-mill patch series, now have to be split in at least three waves (prepare the core, update external platforms, switch over the core). With in-tree platforms, the approach is of course the same, the difference is that these stages can be managed, and merged, in a unified series of commits. Addressing external dependencies by splitting work into sub-series slows development to a crawl. (BaseTools is no exception. I've agreed to splitting it out because the demand for that seems to be huge, and with careful maintenance of "pip-requirements.txt", and with the features offered by pip virtual environments, it appears technically possible. Conceptually, with these bits in place, the BaseTools <-> edk2 dependency tracking should not lose any safety. It *will* lose efficiency.) Furthermore , I disagree with your "burden to all core contributors" and "doesn't bring value to the project" statements 100%. - I *am* a core contributor (feel free to look up the patches I've contributed, with git-log), - DynamicTablesPkg, EmulatorPkg, FmpDevicePkg, IntelFsp2Pkg, IntelFsp2WrapperPkg, SignedCapsulePkg, SourceLevelDebugPkg, StandaloneMmPkg, UefiPayloadPkg, UnitTestFrameworkPkg carry exactly zero interest for me, - but they are also exactly zero burden to me. So your statement "burden to all core contributors" is false (EmulatorPkg in particular is a platform which sometimes does break), and it does not bother me at all. Then, having bhyve in-tree *does* bring value to the project, because it simplifies the testing and development of core edk2 modules on a new, thus far not officially targeted, hypervisor platform. It exposes edk2 to a wider audience; people using FreeBSD as their everyday desktop will have an easier time running and hopefully developing edk2. Laszlo