search

facebookarchive / osf-builder

osf-builder contains tools to build OSF (Open System Firmware) firmware images, and to keep track of their versioning information.
MIT License
7 stars 2 forks source link

Some more changes and add OCP Delta Lake support #10

Closed johnnylinwiwynn closed 3 years ago

johnnylinwiwynn commented 3 years ago

@rojer9-fb @insomniacslk @jonzhang-fb

johnnylinwiwynn commented 3 years ago

This public osf-builder repo is supposed to only contain example project (QEMU serves the purpose) for demonstration purpose. It is better to submit the DeltaLake project data to OCP repo. Before making initial commit to OCP repo, could we make a private github repo to host OCP OSF submission data, so that FB, Intel and 9E could review first, and then OCP OSF leads?

If only adding Delta Lake support to OCP github, then this PR please don't take commit "Add OCP Delta Lake support", and I will upload the commit as a patch file to OCP github, and the flow would be git clone osf-builder, then apply the patch file. If adding Delta Lake support is merged in osf-builder, then I would only upload the documents and the scripts for cloning osf-builder to OCP github. Either way should work. I find I am not allowed to set my forked OCP github to private, so maybe I can provide patch files for private review with Intel, FB and 9elements first.

johnnylinwiwynn commented 3 years ago

Often the time, the blobs are held in 3 different places: IFD/ME in a folder (COREBOOT_MB_BLOBS_DIR), FSP binaries in a folder (COREBOOT_FSP_DIR), MCB in a folder (COREBOOT_MCB_DIR).

How about us defining 3 different environment variables? And if COREBOOT_BLOBS_DIR is assigned, those 3 different environment variables are set to same value, eg. the value of COREBOOT_BLOBS_DIR.

If COREBOOT_BLOBS_DIR is not defined/assigned, it would use the blobs defined by COREBOOT_MB_BLOBS_DIR, COREBOOT_FSP_DIR and COREBOOT_MCB_DIR, right? It would be more inconvenient for coreboot-spr-sp because all those blobs are already located and uploaded in the codebase, which requires some replacing those file paths and names.

jonzhang-fb commented 3 years ago

This public osf-builder repo is supposed to only contain example project (QEMU serves the purpose) for demonstration purpose. It is better to submit the DeltaLake project data to OCP repo. Before making initial commit to OCP repo, could we make a private github repo to host OCP OSF submission data, so that FB, Intel and 9E could review first, and then OCP OSF leads?

If only adding Delta Lake support to OCP github, then this PR please don't take commit "Add OCP Delta Lake support", and I will upload the commit as a patch file to OCP github, and the flow would be git clone osf-builder, then apply the patch file. If adding Delta Lake support is merged in osf-builder, then I would only upload the documents and the scripts for cloning osf-builder to OCP github. Either way should work. I think the first way is preferred, because 1) DeltaLake support will be maintained and updated, when there is code change, there will be corresponding release note (also maybe user guide) changes, and those are in OCP OSF git hub. 2) This public osf-builder should have scope limited to build scripts, methods to get code base. Once the first way is in place, we will update the readme file of this public osf-builder repo, to list OCP OSF github repo as a consumer of the public osf-builder repo. I find I am not allowed to set my forked OCP github to private, so maybe I can provide patch files for private review with Intel, FB and 9elements first. You do not need to fork OCP github. Just create a personal github repo, holding the data to be submitted. Once the repo is reviewed by Intel, FB and 9E, create a patch for OCP OSF github repo.

jonzhang-fb commented 3 years ago

Often the time, the blobs are held in 3 different places: IFD/ME in a folder (COREBOOT_MB_BLOBS_DIR), FSP binaries in a folder (COREBOOT_FSP_DIR), MCB in a folder (COREBOOT_MCB_DIR). How about us defining 3 different environment variables? And if COREBOOT_BLOBS_DIR is assigned, those 3 different environment variables are set to same value, eg. the value of COREBOOT_BLOBS_DIR.

If COREBOOT_BLOBS_DIR is not defined/assigned, it would use the blobs defined by COREBOOT_MB_BLOBS_DIR, COREBOOT_FSP_DIR and COREBOOT_MCB_DIR, right? It would be more inconvenient for coreboot-spr-sp because all those blobs are already located and uploaded in the codebase, which requires some replacing those file paths and names. Correct. The bin directory in coreboot-spr-sp is temporary, the contents should be moved to osf-builder repo in review.coreboot.org, since we do not want extra directories in coreboot-spr-sp repo comparing to coreboot repo.