From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] FW: Discussion: Basetools a separate repo To: Laszlo Ersek ,devel@edk2.groups.io From: "Matthew Carlson" X-Originating-Location: Everett, Washington, US (50.34.40.43) X-Originating-Platform: Windows Chrome 81 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Tue, 21 Apr 2020 17:05:55 -0700 References: <47363f23-b979-c587-ed8c-0e894f13157f@redhat.com> In-Reply-To: <47363f23-b979-c587-ed8c-0e894f13157f@redhat.com> Message-ID: <23498.1587513955969647293@groups.io> Content-Type: multipart/alternative; boundary="MCe9lr3elVXAEh285mSk" --MCe9lr3elVXAEh285mSk Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Lazlo, This is a great point of discussion. Just to make sure we're on the same p= age, let me paraphrase your scenario. Two features at the same time or a im= properly tested new feature were committed in BaseTools=C2=A0and a new rele= ase was spun out. EDK2 was updated to have it's pip-requirements.txt to poi= nt to the new version committed. In an ideal world, CI should catch the bui= ld break for MdeModulePkg but let's say it didn't catch it. Your scenario i= s, how do you go back to the previous version of basetools that EDK2 used o= r perhaps go the the version of BaseTools that last worked. There are several great ways to do this. The release cadence of a pip base= d BaseTools hasn't really been discussed but one option was every feature i= n BaseTools would be a new release (this would be easy to do via pipelines)= . The exact versioning would need to be discussed but there would likely be= some notion of breaking changes with major and minor version. This means t= hat you would be able to easily pip install the basetools 1:1 with the feat= ure commit history. In the scenario you mentioned, it would be easy to roll= back to C0, just "pip install -r the previous requirements file". If a vir= tual environment is setup, this pip install would be entirely localized to = the workspace the user is operating in. The git show command you mentioned = would show the pip-requirements file. We would likely tag the pip_requireme= nts file to a specific release of BaseTools and there might be another file= like pip_suggestions that would allow for a looser version such as 0.3.x w= ere any minor version in 0.3 is fine. That said, determining what exact bas= etools was used in a given build would likely be best accomplished through = build artifacts. We have a BuildToolsReport generator that specifically doe= s this ( https://github.com/tianocore/edk2/tree/master/BaseTools/Plugin/Bui= ldToolsReport ) and it would generate a report that would detail the exact = pip version used in that build. Without build artifacts, it grows a little = bit more fuzzy, but you can have reasonable confidence since it would need = to at least conform to pip suggestions and likely was on pip_requirements. = To summarize, moving back in time is simple and even trivial with minimal d= elay to a developer (pip installs are usually sub-second procedures). There= might even be a part of edksetup that might do the pip install for you if = that's what the community wants. Going to the next step, if you wanted to debug the BaseTools at C1, you mi= ght want to generate a diff of the basetools to try and see where the error= and compare the diff. This I think better addresses your question of bisec= tability (not sure if that's a word). You could clone the basetools repo an= d do a pip install -e {path to basetools}. You would checkout the version i= n C1 pip_requirements and generate the diff between it and C0. Then you cou= ld apply changes or revert changes and test them locally as the basetools u= sed in your edk2 repo will be the local repo you cloned. Once you're done, = simply do a pip install of your pip_requirements file and the symlinks will= be overwritten and things will go back to the way they were before. Hopefully that addresses your concerns. Thanks, - Matthew Carlson --MCe9lr3elVXAEh285mSk Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Lazlo,

This is a great point of discussion. Just to make sur= e we're on the same page, let me paraphrase your scenario. Two features at = the same time or a improperly tested new feature were committed in BaseTool= s and a new release was spun out. EDK2 was updated to have it's pip-re= quirements.txt to point to the new version committed. In an ideal world, CI= should catch the build break for MdeModulePkg but let's say it didn't catc= h it. Your scenario is, how do you go back to the previous version of baset= ools that EDK2 used or perhaps go the the version of BaseTools that last wo= rked.

There are several great ways to do this. The release caden= ce of a pip based BaseTools hasn't really been discussed but one option was= every feature in BaseTools would be a new release (this would be easy to d= o via pipelines). The exact versioning would need to be discussed but there= would likely be some notion of breaking changes with major and minor versi= on. This means that you would be able to easily pip install the basetools 1= :1 with the feature commit history. In the scenario you mentioned, it would= be easy to roll back to C0, just "pip install -r the previous requirements= file". If a virtual environment is setup, this pip install would be entire= ly localized to the workspace the user is operating in. The git show comman= d you mentioned would show the pip-requirements file. We would likely tag t= he pip_requirements file to a specific release of BaseTools and there might= be another file like pip_suggestions that would allow for a looser version= such as 0.3.x were any minor version in 0.3 is fine. That said, determinin= g what exact basetools was used in a given build would likely be best accom= plished through build artifacts. We have a BuildToolsReport generator that = specifically does this (https://github.com/tianocore/edk2/tree/master/BaseTools/Plugin/BuildToolsR= eport) and it would generate a report that would detail the exact pip v= ersion used in that build. Without build artifacts, it grows a little bit m= ore fuzzy, but you can have reasonable confidence since it would need to at= least conform to pip suggestions and likely was on pip_requirements. To su= mmarize, moving back in time is simple and even trivial with minimal delay = to a developer (pip installs are usually sub-second procedures). There migh= t even be a part of edksetup that might do the pip install for you if that'= s what the community wants. 

Going to the next step, if you= wanted to debug the BaseTools at C1, you might want to generate a diff of = the basetools to try and see where the error and compare the diff. This I t= hink better addresses your question of bisectability (not sure if that's a = word). You could clone the basetools repo and do a pip install -e {path to = basetools}. You would checkout the version in C1 pip_requirements and gener= ate the diff between it and C0. Then you could apply changes or revert chan= ges and test them locally as the basetools used in your edk2 repo will be t= he local repo you cloned. Once you're done, simply do a pip install of your= pip_requirements file and the symlinks will be overwritten and things will= go back to the way they were before.

Hopefully that addresses y= our concerns. 

Thanks,
- Matthew Carlson --MCe9lr3elVXAEh285mSk--