On 06/03/15 13:34, Paolo Bonzini wrote:
>
>
> On 03/06/2015 13:14, Laszlo Ersek wrote:
>> 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".
>
> You would have N clones, one per subpackage. Each patchset would be
> split into multiple series, one per subpackage, each fully bisectable.
> You'd commit and push each patchset separately. Once you're done, one
> final patch would atomically update all the subpackages at once.
>
>> - 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.
>
> No, submodules can do this. A "master commit hash" includes a list of
> subpackage commit hashes.
>
> You'd have to remind the contributor to run "git submodule update" after
> checking out the master commit hash.
>
>>> 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?
>
> You would remove it from IntelFrameworkPkg, add it to MdePkg, and commit
> a single atomic change for both to the master repository.
>
>> 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.
>
> Bisectability would be extremely painful, because bisection on the
> master repository would leave you at the single huge commit where you
> atomically update all subpackages. You would have no clue of how to
> bisect _within_ that atomic update, in fact in some case you cannot.
Thanks for the education.
Although bisectability has not been treated as a primary goal across all
of edk2 (unfortunately!), in OvmfPkg we always consider it a first class
goal -- that's how one find bugs and supports users --, and the project
in general should move towards bisectability (and more focused, fine
grained patches), not away from them.
In fact the scenario you described is the original BaseTools situation
all over. Frequently when a BaseTools sync happened, stuff would break,
and users would be left with an unbisectable, multi-KLOC BaseTools patch
to eyeball.
>>> 2. git submodule foreach “command” can be used to run command on
>>> every package, for example git submodule foreach "git pull"
>
> This is not enough. A diff between two consecutive commits in the
> master repository would just say something like
>
> --- a/IntelFrameworkPkg
> +++ b/IntelFrameworkPkg
> -Submodule hash 0123456789
> +Submodule hash abcdef0123
> --- a/OvmfPkg
> +++ b/OvmfPkg
> -Submodule hash 456789abcd
> +Submodule hash ef01234567
>
> and so on. It wouldn't give a clue of how the source changed in the
> packages. You can change it to log the added commits ("git diff
> --submodule=log" or "git config diff.submodule log"), but not to show
> the diffs.
>
> In short, it would be extremely painful.
Thanks!
Laszlo
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
