From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] RFC for Edk2-Library To: Michael D Kinney ,devel@edk2.groups.io From: "Sean" X-Originating-IP: 50.47.106.228 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Thu, 09 May 2019 19:48:13 -0700 References: In-Reply-To: Message-ID: <19931.1557456493073446522@groups.io> Content-Type: multipart/alternative; boundary="TjbYFiu0gxo8ud9IVmGU" --TjbYFiu0gxo8ud9IVmGU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 1. Agree on the name but not sure whats better.=C2=A0 i don't think it shou= ld be edk2-tools because the idea of this is to be a library of support cod= e but not the tools themselves.=C2=A0 This limits dependencies and keeps th= e library free of business specific logic.=C2=A0 The second RFC will be for= a new repo that is more like edk2-tools.=C2=A0 So maybe this could be edk2= -tools-library? 2. Future direction (edk2 having a dependency on this package).=C2=A0 I do= n't think this library will achieve my goals if it doesn't start to pull in= support libraries from basetools.=C2=A0 The simplest example is the parser= s.=C2=A0 It would seem foolish to have two copies.=C2=A0 It would be great = to have one set of parsers that could be used by tool developers as well as= the edk2 build process.=C2=A0 Opening up those tools would make writing ed= k2 analysis tools much easier/faster/better. 3. Pip/distribution/versioning.=C2=A0 I would definitely not want my versi= on of this pip module dependent on my OS distro and version.=C2=A0 This wil= l be something tied to the edk2 platform i am building.=C2=A0 =C2=A0These a= re things that are somewhat stable but i would expect more churn than an OS= and different platforms will have different needs.=C2=A0 i also don't want= to sign up for working with OS vendors to get this into their package mana= gement.=C2=A0 With python 3.5 and newer there is a built in concept of virt= ual environments (venv).=C2=A0 This is how i would handle this problem.=C2= =A0 The Pip modules and their dependencies do not impact the global packag= es.=C2=A0 Only the virtual environment gets updated and a virtual environme= nt can be trivially created/deleted.=C2=A0 This is also expected if you are= building platforms that might be running different versions of edk2 so its= a good idea to create a venv for each code tree on your system and activat= e that venv when doing builds in that code tree. 4. Squash merge/PR process.=C2=A0 We discussed this at length at plugfest = and unfortunately i don't think there was any silver bullet.=C2=A0 Patchset= s and the edk2 process today are a relic of emailing patches.=C2=A0 When yo= u move to pull requests managed by a server with policy and automation i th= ink the only feasible solution is squash merge.=C2=A0 Now i don't understan= d why squash merge means bad commit messages and lost info.=C2=A0 The idea = is that a single PR should be a single feature.=C2=A0 When it gets squashed= the commit message should reflect the feature and be of high quality.=C2= =A0 If the PR was too big and contained numerous features then the PR shou= ld be split up.=C2=A0 Squash merge allows your automation to easily guarant= ee bisect-ability, build-ability, and that each commit will pass the requir= ements.=C2=A0 =C2=A0 Having one continuous PR optimizes your review process= /comment tracking, etc.=C2=A0 I would be strongly opposed to opening new PR= s for every new "version". Thanks Sean --TjbYFiu0gxo8ud9IVmGU Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable 1. Agree on the name but not sure whats better.  i don't think it shou= ld be edk2-tools because the idea of this is to be a library of support cod= e but not the tools themselves.  This limits dependencies and keeps th= e library free of business specific logic.  The second RFC will be for= a new repo that is more like edk2-tools.  So maybe this could be edk2= -tools-library?  

2. Future direction (edk2 having a d= ependency on this package).  I don't think this library will achieve m= y goals if it doesn't start to pull in support libraries from basetools.&nb= sp; The simplest example is the parsers.  It would seem foolish to hav= e two copies.  It would be great to have one set of parsers that could= be used by tool developers as well as the edk2 build process.  Openin= g up those tools would make writing edk2 analysis tools much easier/faster/= better.  

3. Pip/distribution/versioning.  I woul= d definitely not want my version of this pip module dependent on my OS dist= ro and version.  This will be something tied to the edk2 platform i am= building.   These are things that are somewhat stable but i woul= d expect more churn than an OS and different platforms will have different = needs.  i also don't want to sign up for working with OS vendors to ge= t this into their package management.  With python 3.5 and newer there= is a built in concept of virtual environments (venv).  This is how i = would handle this problem.  The Pip modules and their dependencies do = not impact the global packages.  Only the virtual environment gets upd= ated and a virtual environment can be trivially created/deleted.  This= is also expected if you are building platforms that might be running diffe= rent versions of edk2 so its a good idea to create a venv for each code tre= e on your system and activate that venv when doing builds in that code tree= .  

4. Squash merge/PR process.  We discussed thi= s at length at plugfest and unfortunately i don't think there was any silve= r bullet.  Patchsets and the edk2 process today are a relic of emailin= g patches.  When you move to pull requests managed by a server with po= licy and automation i think the only feasible solution is squash merge.&nbs= p; Now i don't understand why squash merge means bad commit messages and lo= st info.  The idea is that a single PR should be a single feature.&nbs= p; When it gets squashed the commit message should reflect the feature and = be of high quality.  If the PR was too big and contained numerous feat= ures then the PR should be split up.  Squash merge allows your automat= ion to easily guarantee bisect-ability, build-ability, and that each commit= will pass the requirements.    Having one continuous PR optimize= s your review process/comment tracking, etc.  I would be strongly oppo= sed to opening new PRs for every new "version".  

Than= ks
Sean --TjbYFiu0gxo8ud9IVmGU--