1. Agree on the name but not sure whats better. 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. This limits dependencies and keeps the 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 dependency on this package). I don't think this library will achieve my goals if it doesn't start to pull in support libraries from basetools. The simplest example is the parsers. It would seem foolish to have 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. Opening up those tools would make writing edk2 analysis tools much easier/faster/better. 3. Pip/distribution/versioning. I would definitely not want my version of this pip module dependent on my OS distro and version. This will be something tied to the edk2 platform i am building. These are things that are somewhat stable but i would 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 get 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 updated and a virtual environment can be trivially created/deleted. 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. 4. Squash merge/PR process. We discussed this at length at plugfest and unfortunately i don't think there was any silver bullet. Patchsets and the edk2 process today are a relic of emailing patches. When you move to pull requests managed by a server with policy and automation i think the only feasible solution is squash merge. Now i don't understand why squash merge means bad commit messages and lost info. The idea is that a single PR should be a single feature. 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 features then the PR should be split up. Squash merge allows your automation to easily guarantee bisect-ability, build-ability, and that each commit will pass the requirements. Having one continuous PR optimizes your review process/comment tracking, etc. I would be strongly opposed to opening new PRs for every new "version". Thanks Sean -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#40393): https://edk2.groups.io/g/devel/message/40393 Mute This Topic: https://groups.io/mt/31536886/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
