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
> to go 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.
In the project I'm playing with in the root of the main git tree there is a
.gitmodules file that lists path and URL of the submodule. This submodule is a
git wrapper for another svn code base. So if the submodule is Foo I can `cd
Foo` and `git pull` to grab the TOT. If I do `cd ..` `git pull` It updates the
main repository. There seems like there should be some workflow that works for
this with git? Maybe there is a way to test and make patches in the submodule
and them commit to the raw git repo?
> I like the idea to get a directory structure such as
> Platform/<Vendor>/<PlatformNamePkg>.
>
> FYI, I was also told that what I am currently doing for the ARM Platforms is
> not compliant with the UEFI packaging spec. This spec does not support
> packages under packages (eg: ArmPlatformPkg/ArmVExpressPkg).
>
> It would be nice to get a 'Driver' directory as well. Today, drivers are
> spread over the packages that do not make really easy to find them.
> And potentially having all the drivers into a same root directory could allow
> some drivers to benefit fixes from other driver (eg: an engineer working on a
> Ethernet driver could compare what other Ethernet drivers do and could find
> issues in those drivers).
> I would not be surprise if we start to see more and more Open Source UEFI
> driver contributions – an appropriate location in the EDK2 repository would
> probably be welcome.
>
Sounds like a good idea.
Thanks,
Andrew Fish
> From: Andrew Fish [mailto:af...@apple.com]
> Sent: 25 July 2013 00:57
> To: Chip Ueltschey
> Cc: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] Platform Specific Contribution
>
>
> On Jul 24, 2013, at 4:51 PM, Chip Ueltschey <chipj...@gmail.com> wrote:
>
>
> I think it would be good to find some way to organize this better.
> Currently the DuetPkg and Nt32Pkg are part of the UDK releases. I think it
> would be better to have a grouping of packages related to emulator support
> that included these as well as EmulatorPkg, UnixPkg and OvmfPkg, and then
> remove those packages from the set of UDK packages.
>
> This sounds fine to me.
>
>
> The platform specific packages are at least not included in the UDK set, but
> I certainly agree that it would better to group them somehow.
> It seems odd to me that all this sort of packages are located in the
> edk2/trunk.
> I am very unfamiliar with how git reads into this (being a svn user today),
> but it seems like thinks would be better with a slightly less flat structure.
>
> I agree 100%.
>
> Thanks,
>
> Andrew Fish
>
>
> -chip
>
>
>
> On Wed, Jul 24, 2013 at 9:41 AM, Andrew Fish <af...@apple.com> wrote:
> I've not seen any thoughts on this so here goes. Some one who understands
> source control better than me might have a better idea.
>
> I think something like this could work with git.
>
> Add a Platform directory to /trunk/edk2. Move EmulatorPkg, Nt32Pkg, OvmfPkg
> (we could make this a separate project too) and an other publicly available
> emulation environments into this directory. Remove hardware platforms.
>
> Then add N projects to support hardware platforms, maybe per company, or per
> project. A platform project looks like:
>
> git submodules of a specific version of the edk2 tree (fat driver, etc.). It
> could point to an svn branch that contains patches that are not yet merged
> into the mainline.
> Platfom/BeagleBoardPkg is then a git submodule
>
> So the N projects are hosted in a different svn/git than the ekd2, and then
> there is a git project that represents an edk2 version, plus a specific set
> of platform code. This means platform consumers can just pull a single item.
> The project git can be the working copy that users download, and the repo
> where platform code lives could be for TOT development.
>
> So again I'm no git expert but I've used a git project that has a submodule
> that is an svn remote. The strange thing is you end up doing git pull from .
> and Platfom/BeagleBoardPkg. Some one who knows git/svn better, may know a
> better way to do this, but at least something like this scales to a large
> number of platforms.
>
> Thanks,
>
> Andrew Fish
>
>
> On Jul 22, 2013, at 1:07 PM, Sivasakthivel Nainar <sivasakthiv...@ami.com>
> wrote:
>
> > Hi All,
> > Is Tianocore.org supports platform specific contribution? I have seen
> > couple of Arm Platform sources in ArmPlatformPkg and Ti BeagleBoard
> > source. If so, Who is the contact point for creating such packages?
> >
> > Thanks
> > Siva
> >
> > The information contained in this message may be confidential and
> > proprietary to American Megatrends, Inc. This communication is intended to
> > be read only by the individual or entity to whom it is addressed or by
> > their designee. If the reader of this message is not the intended
> > recipient, you are on notice that any distribution of this message, in any
> > form, is strictly prohibited. Please promptly notify the sender by reply
> > e-mail or by telephone at 770-246-8600, and then delete or destroy all
> > copies of the transmission.
> >
> > ------------------------------------------------------------------------------
> > 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
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
