[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 By far I think it is preferable to have everything in one repository, 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. 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. 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. 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
