On 06/03/15 11:50, Gao, Liming wrote: > Hi, all > > Now, EDKII project Git mirror is ready in GitHub (https:// > <https://github.com/tianocore>github.com/tianocore > <https://github.com/tianocore>). There are EDKII project Repo and each > package Repo. After migrate EDKII from SVN to GitHub, EDKII Git Repo > will be writable, EDKII SVN project will become mirror. I expect to keep > write access in the centralized Git repo. But, EDKII project Repo (edk2) > and MdePkg Repo (edk2-MdePkg) includes the same source code. So, only > one of them will be writable. My proposal is to make Package Repo be > Read & Write, and update EDKII project to link each package by submodule > way. The benefit of this way is: > > 1. EDKII project is too big. After separate them, the developers > can just pull their used packages instead of full.
The Linux kernel is arguably bigger, and pulling it all poses no problem. I'm not very familiar with git submodules, but from a quick skim of git-submodule(1), I have to ask the following questions: - Assuming I have a longer patchset that modifies, let's say, 4 top level packages, can I commit all those patches in my clone? And can I push the full series to my fork on github? Because, the manual page says, "you cannot modify the contents of the submodule from within the main project". - Assume I'd like to advise a user to build OVMF at a "known good state" of the edk2 tree. Right now I can do this by naming a single SVN revision (or git commit hash, preferably); that implies the *full* state of the edk2 tree, including all non-OvmfPkg modules that OvmfPkg pulls into the build. Wouldn't submodules prevent this? I'd like to avoid a mixture of submodule versions after a checkout. The git-submodule(1) manual mentions the "subtree merge strategy", but I don't know what that is. > 2. The different packages have the different owners. After > separate them, the package owner can give write access for the different > developers. What matters is patch review / acceptance from the package owner. I have committed patches to non-OvmfPkg modules after getting R-b tags from the respective modules' owners. I would not have been able to do this if I had needed separate write access to each top level directory. On the other hand, there have been a few cases when people committed to OvmfPkg without our review. :( So, for me this is a question of track record and trust, not enforcement by technical means. I think controlling write access on the package level would do more harm than good. > 3. Close source project can refer to EDKII packages. Those project > can be easily setup by git submodule. Okay, *now* I understand the motivation for this. For me this point is neither negative nor positive; I'm neutral. But points 1 and 2, probably in the service of point 3, *are* negative for me. > Compared to EDKII project Repo, submodule EDKII project Repo just > includes edksetup.bat, and edksetup.sh. Some BKM of submodule is shared > here. What is BKM? > > 1. Every Git operation is took for Package Repo. Pull, Branch, > Commit, Create Patch, Fork, and Pull Request are all for Package Repo. > If your patch changes multiple packages, you need to commit and create > patch per Package. We do that already, just for review's sake. However, there have been a few (very few) patches that had to straddle packages. What happens for example if you move a type definition from IntelFrameworkPkg to MdePkg, due to advances in the UEFI specification? I'm not saying this is impossible to solve with careful patches, but I'm very concerned that this (especially in combination with the submodules) will break bisectability. > 2. git submodule foreach “command” can be used to run command on > every package, for example git submodule foreach "git pull" In my (limited) experience, git submodule is there for independent (independently developed) packages. For example, a low level library can be a git submodule in a main git repo for an application (that is the client of the library). I think there are many more inter-dependencies in edk2 than that. Edk2 development does not occur *only* along protocol, PPI, and library class boundaries. Theoretically that might be possible, but it would require *extreme* discipline in development (very focused patches, all developers building all series at all stages before submitting, and so on). So, as long as my "vote" counts, I vote against this proposal. I can't see any benefits, and I can see a whole bunch of risks. (Obviously I'm open to being educated about git-submodule.) Jordan, what is your opinion? (Note I'm not asking you to agree with me.) Thanks Laszlo ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
