> From: Ryan Harkin [mailto:ryan.har...@linaro.org] > Sent: 29 July 2013 16:42 > To: Grant Likely > Cc: edk2-devel@lists.sourceforge.net; Olivier Martin > Subject: Re: [edk2] Platform Specific Contribution > > 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:
This thread started about platform specific contributions but it's expanding to cover other repository management issues. I thought I'd just go ahead and list all the repo management issues I see. Firstly, like others have said, I'd like to see EDK2 move from svn to git. There's a lot of unnecessary conversion from one to the other and git seems to be most engineers' preferred choice. I agree with Olivier/Grant/Ryan that git submodules could be painful to manage (for the same reasons they list). I don't see a scalability problem with having all platforms in the mainline; the linux kernel mainline manages this and that's a much bigger tree. I guess having lots of platforms raises some access control issues; currently any package maintainer can push to any other package. Increasing the number of people with commit rights increases the risk of bad commits. As Grant/Ryan say, this could be partially managed by a select group servicing pull requests from external repos. However, I think we would also need each company to have a designated maintainer with commit access, otherwise there is little incentive for other edk2 maintainers to pull platform code. Some companies might delegate maintainership of their directory to a 3rd party (e.g. Linaro). If there ends up being a significant number of additional maintainers with commit rights, access could be limited to each maintainer's director(y|ies) using a tool like gitolite or gerrit. Where everyone seems to agree is the platform package naming structure needs fixing. I'm happy with Andrew's suggestion, elaborated by Ryan. I also agree with Olivier's suggestion of a root "Driver" directory. While we're at it, we could also bring FatPkg and BaseTools into the EDK2 mainline. The former has an additional licensing term (see https://svn.code.sf.net/p/edk2-fatdriver2/code/trunk/FatPkg/License.txt) but I don't think that's a good enough reason to keep it separate. I guess the separation might be due to historical FAT licensing issues (e.g. each company having to seek their own license) but the Microsoft FAT license now explicitly allows use of FAT in any U(EFI) implementation so users of this package are no longer exposed to onerous licensing terms. BaseTools development seems to be suffering from being in a different repository and there doesn't seem to be a good reason for it to be separate. Perhaps it would get more attention as part of the main repository? Another minor tweak could be to put ArmPkg, IntelFrameworkPkg, IntelFrameworkModulePkg under a root "Arch" directory. But I don't feel strongly about that as there currently aren't a lot of other architectures in UEFI to worry about. Regards Dan. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
