1. Agree on the name but not sure whats better.&nbsp; i don't think it should be edk2-tools because the idea of this is to be a library of support code but not the tools themselves.&nbsp; This limits dependencies and keeps the library free of business specific logic.&nbsp; The second RFC will be for a new repo that is more like edk2-tools.&nbsp; So maybe this could be edk2-tools-library?&nbsp;&nbsp;<br /><br />2. Future direction (edk2 having a dependency on this package).&nbsp; I don't think this library will achieve my goals if it doesn't start to pull in support libraries from basetools.&nbsp; The simplest example is the parsers.&nbsp; It would seem foolish to have two copies.&nbsp; It would be great to have one set of parsers that could be used by tool developers as well as the edk2 build process.&nbsp; Opening up those tools would make writing edk2 analysis tools much easier/faster/better.&nbsp;&nbsp;<br /><br />3. Pip/distribution/versioning.&nbsp; I would definitely not want my version of this pip module dependent on my OS distro and version.&nbsp; This will be something tied to the edk2 platform i am building.&nbsp; &nbsp;These are things that are somewhat stable but i would expect more churn than an OS and different platforms will have different needs.&nbsp; i also don't want to sign up for working with OS vendors to get this into their package management.&nbsp; With python 3.5 and newer there is a built in concept of virtual environments (venv).&nbsp; This is how i would handle this problem.&nbsp; The Pip modules and their dependencies do not impact the global packages.&nbsp; Only the virtual environment gets updated and a virtual environment can be trivially created/deleted.&nbsp; 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 activate that venv when doing builds in that code tree.&nbsp;&nbsp;<br /><br />4. Squash merge/PR process.&nbsp; We discussed this at length at plugfest and unfortunately i don't think there was any silver bullet.&nbsp; Patchsets and the edk2 process today are a relic of emailing patches.&nbsp; When you move to pull requests managed by a server with policy and automation i think the only feasible solution is squash merge.&nbsp; Now i don't understand why squash merge means bad commit messages and lost info.&nbsp; The idea is that a single PR should be a single feature.&nbsp; When it gets squashed the commit message should reflect the feature and be of high quality.&nbsp; If the PR was too big and contained numerous features then the PR should be split up.&nbsp; Squash merge allows your automation to easily guarantee bisect-ability, build-ability, and that each commit will pass the requirements.&nbsp; &nbsp; Having one continuous PR optimizes your review process/comment tracking, etc.&nbsp; I would be strongly opposed to opening new PRs for every new "version".&nbsp;&nbsp;<br /><br />Thanks<br />Sean