From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2 To: Laszlo Ersek ,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 10:25:00 -0700 References: <6ef172e5-4999-f1bc-0d08-43685b03f5ce@redhat.com> In-Reply-To: <6ef172e5-4999-f1bc-0d08-43685b03f5ce@redhat.com> Message-ID: <21546.1583861100642932695@groups.io> Content-Type: multipart/alternative; boundary="powWMHCyoMM4Zf4pj7Mu" --powWMHCyoMM4Zf4pj7Mu Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I don't see the difference besides the mechanics of the operation (which yo= u have described clearly).=C2=A0 To guarantee a repo or repos is "git-bisec= table" you need to build and test every commit on your platform.=C2=A0 For = example in the recent ArmMmuLib patchset, you were able to build every comm= it in the patch to identify which one caused the break.=C2=A0 There isn't a= n enforced process in place to ensure that happens within Edk2.=C2=A0 Thank= fully the review process and the developers knowledge allowed the commits t= o be made in such a way that this was possible.=C2=A0 That doesn't have to = change when you move to a submodule.=C2=A0 Also you could put automation in= place to enforce and/or test for this scenario.=C2=A0 You can put automati= on in place to "integrate" into your super project at every commit if you r= eally wanted to and had the resources to run tests on every one of those co= mmits.=C2=A0 Is this type of CI done today for OVMF? Again this is what nearly all platforms have to do today and we have a lot= of experience with bisecting within the submodule to find the error.=C2=A0= The longer you wait between integrations the more costly the bisect is if = you have to do it, but this is a choice of the super project owner / platfo= rm owner.=C2=A0 Today I assume you make those choices too, they just happen= to be within the same repo.=C2=A0 I also assume that if you found the MmuL= ib bug in a few days you probably wouldn't bisect all the changes but you w= ould review the history to intelligently guess at the most likely candidate= s and bisect within those commits. In the end I just don't see the big difference to the platform (OVMF in th= is case) but I do see the reduced size/noise/content helping all platforms.= = =C2=A0 Success still relies on good development practices, regular builds,= and testing. Thanks Sean --powWMHCyoMM4Zf4pj7Mu Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I don't see the difference besides the mechanics of the operation (which yo= u have described clearly).  To guarantee a repo or repos is "git-bisec= table" you need to build and test every commit on your platform.  For = example in the recent ArmMmuLib patchset, you were able to build every comm= it in the patch to identify which one caused the break.  There isn't a= n enforced process in place to ensure that happens within Edk2.  Thank= fully the review process and the developers knowledge allowed the commits t= o be made in such a way that this was possible.  That doesn't have to = change when you move to a submodule.  Also you could put automation in= place to enforce and/or test for this scenario.  You can put automati= on in place to "integrate" into your super project at every commit if you r= eally wanted to and had the resources to run tests on every one of those co= mmits.  Is this type of CI done today for OVMF?  

Again this is what nearly all platforms have to do today and we have a lot= of experience with bisecting within the submodule to find the error. = The longer you wait between integrations the more costly the bisect is if = you have to do it, but this is a choice of the super project owner / platfo= rm owner.  Today I assume you make those choices too, they just happen= to be within the same repo.  I also assume that if you found the MmuL= ib bug in a few days you probably wouldn't bisect all the changes but you w= ould review the history to intelligently guess at the most likely candidate= s and bisect within those commits.

In the end I just don't see t= he big difference to the platform (OVMF in this case) but I do see the redu= ced size/noise/content helping all platforms.  Success still relies on= good development practices, regular builds, and testing.    = ;

Thanks
Sean

   --powWMHCyoMM4Zf4pj7Mu--