From: "Sean" <sean.brogan@microsoft.com>
To: Michael D Kinney <michael.d.kinney@intel.com>,devel@edk2.groups.io
Subject: Re: [edk2-devel] RFC for Edk2-Library
Date: Thu, 09 May 2019 19:48:13 -0700 [thread overview]
Message-ID: <19931.1557456493073446522@groups.io> (raw)
In-Reply-To: <E92EE9817A31E24EB0585FDF735412F5B9CA5918@ORSMSX113.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3014 bytes --]
next prev parent reply other threads:[~2019-05-10 2:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-07 21:35 RFC for Edk2-Library Sean
2019-05-08 9:55 ` [edk2-devel] " Laszlo Ersek
2019-05-09 18:06 ` Michael D Kinney
2019-05-09 22:55 ` Laszlo Ersek
2019-05-10 0:01 ` Michael D Kinney
2019-05-10 2:23 ` Michael D Kinney
2019-05-10 2:48 ` Sean [this message]
2019-05-13 14:46 ` Laszlo Ersek
2019-05-13 10:46 ` Laszlo Ersek
2019-05-13 18:20 ` Michael D Kinney
2019-05-13 20:28 ` Laszlo Ersek
2019-05-23 2:32 ` Michael D Kinney
2019-05-30 2:15 ` [edk2-devel] RFC for edk2-tools-library v2 previously known as " Sean
2019-05-31 17:39 ` Sean
2019-05-31 23:22 ` Michael D Kinney
2019-06-28 20:39 ` Sean
2019-06-11 18:40 ` [edk2-devel] " kondal.r.purma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19931.1557456493073446522@groups.io \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox