On 27 July 2013 21:50, Grant Likely <grant.lik...@secretlab.ca> wrote:
> [cc'ing ryan; he already has to deal with keeping multiple platforms
> in sync with mainline]
>
> On Fri, Jul 26, 2013 at 4:06 PM, Andrew Fish <af...@apple.com> wrote:
>> On Jul 25, 2013, at 3:07 AM, Olivier Martin <olivier.mar...@arm.com> wrote:
>>
>> > Grant did some investigation a while ago when Linaro started to work on
>> > UEFI
>> > – see his email
>> > http://lists.linaro.org/pipermail/boot-architecture/2012-December/000192.html
>> >
>> > At some point I was also using 'git submodules' to avoid mixing EDK2 tree
>> > source code with one of the platforms I was working on that was not
>> > intended
>> > togo upstream.
>> > It is quite painful with git-submodules when you want your tree to contain
>> > all the latest head of the sub repositories.
>> > If you want your root EDK2 repository to always track the latest version of
>> > your platform repositories (a sub-directory of your root directory) then
>> > for
>> > every changes in the platform repository you make, you need to commit a
>> > change in the root directory to update the SHA1 of the git-submodule into
>> > the root repository.
>>
>> I'd think we would be splitting up into multiple repositories and use git
>> submodule to stitch together useful sets of things that people can download
>> in a single operation, with an associated web page that helps you get
>> started.
>
> A bit of context for my email: Everything discussed there is based on
> the assumption that mainline will not take platform support code.
> While it's possible to manage the tree that way, it incurs quite a lot
> of overhead. For Linaro it was important because we were trying to
> figure out how to create a long-lived branch to act as mainline for
> various platform support. As Olivier also discovered, it is quite
> painful to maintain.
>
> In the end we did none of the options described in the email. We
> instead took a branch off of edk2 in such a way that we can merge in
> mainline at anytime as well as apply platform support patches[1].
> (Ryan, correct me if I quoted the wrong branch in the below URL).
> However, that is still just bodging around not having platform support
> in mainline.
>
> [1]
> https://git.linaro.org/gitweb?p=arm/uefi/uefi-next.git;a=shortlog;h=refs/heads/linaro-tracking
>
You are correct, that is the Linaro "mainline" after all my merges, etc.
And you are also right to say that this is just bodging around not
having platform code in mainline.
> By far I think it is preferable to have everything in one repository,
Agree - strongly :-)
> for several reasons:
> - There never is any question about which versions of trees are needed
> to work together. It is implicit in the fact that there is only one
> repo.
> - It becomes possible to do cross-tree cleanups and consolidation that
> affects multiple platforms, or core code and platforms. For example,
> you may notice that three platforms are doing exactly the same thing
> and really should have a common utility function.
> - Same goes for bug fixes. My experience has been that bugs found in
> one board port often show up in others.
> - It's easier to deal with C ABI changes (I'm talking about direct C
> calls here, not stabilized protocols) when you have access to the call
> sites. We've had this exact problem in ARM when Olivier has needed to
> make a change to the core ARM support code, and that change has needed
> to be propagated to all of the ARM board support.
> - The workflow is *simple*.
> - Finally, from the project health perspective, I think it gets
> developers thinking about mainline instead of just their local project
> tree, and it gets them involved sooner since there will be
> encouragement to get there code into mainline.
>
> And we can do that with git without giving everyone direct commit
> access to the master repository. There would still need to be a one or
> more developers with core commit access, but other maintainers could
> send pull requests from their own public repository to get things
> merged into mainline.
Yes, that's how I'd prefer to do it.
Having spent the last 18 months maintaining a hacked up EDKII git
tree, I've tried various methods, but in the end, just having one
master git repo with everything that we need merged into it was the
best way to go.
I agree with the previous suggestions of having a Platform (or similar
top level directory) with packages inside that. Olivier made the
point that sub-packages is wrong, but I think there needs to be some
sort of layering, whether or not each layer is a package or just a
directory containing packages.
Sub-dirs based on Vendor seems to be the most common approach when you
look at other project (like the linux kernel or u-boot).
So something like this would make sense to me:
edk2
- Platform
- Arm
- VExpressPkg
- VersatilePkg
- ArmCommonPkg
- Samsung
- OrigenPkg
- ArndalePkg
- SamsungCommonPkg
- TI
- BeaglePkg
- PandaPkg
- TiCommonPkg
(I've omitted the idea of a Plaform level Drivers or Common package,
but I also think that's an important topic to be agree, if we are to
maintain a tree with as little code duplication as possible.)
Each of those packages could live in their own git repos happily, so
long as there was a maintainer at the edk2 level who was prepared to
service the pull requests from each maintainer.
If each platform's package repo used the same directory structure, and
they ensured their trees were "fast forward only" (i.e. no re-writing
of history) then all that would be needed would be a simple merge by
the edk2 maintainer. Build and test being a different topic.
If a platform was using a different directory structure, such as
FatDriver2 is today, I found that doing an initial "read-tree"
operation to import the repo means that the maintainer can then simply
merge the latest code from the FatDriver2 repo without having to worry
about the directory structures not matching.
For example, this is how I initially imported the fat driver code into my tree:
# my local clone of the fat dirver repo
# this could (should?) be the actual upstream URL
FAT_URL=/linaro/lt/uefi/git/edk2-fatdriver2.git
# my branch name for the fat driver within my tree
# this can be kept private by the maintainer
FAT_REMOTE=tianocore-edk2-fatdriver2
# I name this the same as the remote name, but it can be different
FAT_BRANCH=$FAT_REMOTE
# add the fat driver code into my edk2 tree
git remote add $FAT_REMOTE $FAT_URL
git checkout --orphan $FAT_REMOTE
git pull $FAT_REMOTE trunk
# merge the fat driver into my "master" branch
git checkout master
git merge -s ours --no-commit $FAT_BRANCH
git read-tree --prefix=FatPkg/ -u $FAT_BRANCH:FatPkg
git commit -s -m "Adding $FAT_BRANCH FatPkg into edk2 tree"
After this, I don't need the $FAT_BRANCH any more, although I do keep
it up-to-date for my own reference. Each time I want to update my
master branch with the latest content of the fat driver tree, I do
this:
# update "master" branch
git checkout master
git remote update $FAT_REMOTE
git pull $FAT_REMOTE trunk
However, overall, I'd favour restructuring the code and/or the trees
so that the fat driver can simply be merged in without this hacking.
>
> The counter point that could be made is that many other project
> successfully pull in multiple projects. Android is a really good
> example, and they use their 'repo' tool to pull in many separate git
> repositories into a single build environment.
I've never liked repo, personally. My experiments with it were not
favourable. I found it to be too much of a compromise when compared
to having multiple trees all merged into one master tree.
The biggest advantage of the single tree approach is the consolidated
history. "repo" just gives you lots of repos and no central history
for everything you're trying to build. It's not bisectable, should
someone else break your platform support.
> However, in my
> experience that is being done to pull together several separate
> independent projects that have a development life of their own
> independent of the meta project. UEFI really doesn't fit in that mode.
Agreed.
> Anyone doing board support is going to be building it directly on top
> of core UEFI; it is not practical to build that component
> independently from mainline tianocore.
>
> (BTW, Just to be clear, I'm not advocating that all board support must
> be mainlined; I can certainly think of several reasons for not wanting
> to mainline code.)
>
> g.
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
