That link didn’t work for me. - Bret Sent: Monday, September 14, 2020 8:59 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Bret Barkelew<mailto:Bret.Barkelew@...>;

JSON Structure would probably be worth discussing. I know that there are other places I’ve seen JSON used and it may end up that we want common business logic (similar to using Oniguruma for regex).

I think code review works. I’m primarily interested in seeing how much code falls under the “edk2” vs “edk2-staging” repos. - Bret Sent: Monday, September 14, 2020 8:12 PM To:

Hi Everyone, Given that we have removed FSP 1.x support from TianoCore in edk2-stable201908, it seems that the 1.x FSP binaries at https://github.com/intel/FSP have become increasingly limited in

Hey Andrew, Your comments were helpful and valid 😊 Part of the appeal of making it into a pip module is that it doesn’t have a specific file system path. Python itself take cares of it and it

Matthew, I did not meant to imply we should optimize for the current installed base, I just think it is useful to think about them. I think Lazlo is pointing out what is best for the project and that

Andrew: I think leveraging the existing edksetup is a great idea. Using the existing EDK_TOOL_PATH variable could work but it seems clunky. Since the pip module wouldn't be a path, it seems strange

I've skimmed: - the earlier discussion linked above (rooted at <https://edk2.groups.io/g/rfc/message/270>), - the even earlier comments in the "Discussion: Basetools a separate repo" thread on

Matthew, I’ll throw out some current developer centric ideas. 1) If you `source edksetup.sh` (edksetup.bat) you get the current behavior, and you add an argument you get the pip flavor? So maybe

Hello all, A recent topic on the RFC mailing list went out and the work on moving Basetools/Sources/Python to a separate repo has started. See the RFC conversation here:

Hi Samer, Comments included below. Mike

Samer, While in the “code 1st state” there are BZ# prefixes to types and globals. So when the code ends up in the specification the “code 1st” branch is going to need to get cleaned up for

Mike, Looks good as a starting point! Acked-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...> I do have a few questions on this sentence: "Specification text changes are held within the

A version of this Wiki page is also provided here for review: https://github.com/mdkinney/edk2/wiki/EDK-II-Code-First-Process Mike

I find that regrettable, because in some (rare!) cases, a commit would really deserve both tags. I agree this is a good general principle; it's always good to make a patch author think explicitly

I'd like to suggest "Type: " rather than "TYPE: ". Furthermore, assuming a consistent use of the "Type: " name (at the beginning of the line), do we really need the '**' value prefix/suffix? On one

Hello Mike, Thanks for your feedback. There are several levels of intent behind our proposal.The one that you mentioned (search and identify commits by certain tag attribute) is important, but not

Hi Artem, We discussed this topic briefly in the EDK II Community meeting this morning With Felix. For the tags topic, I believe the feature being asked for here is a simple way to identify and

On Sat, Aug 1, 2020 at 03:47 PM, Laszlo Ersek wrote: On 08/01/20 00:19, Artem Shchygel wrote:> Hi, All>> In this RFC we're proposing slight changes to Git commit message format tomake it more

Hints are very welcome, but not in subject lines. Please use Name: value Name: value # comment style tags near the end of the commit messages instead. Subject lines are primarily for human