On Mon, Jul 29, 2013 at 12:06 PM, Dan Handley <dan.hand...@arm.com> wrote: >> 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).
I'm not really worried on this point. Maintainership has a lot more to do with individual engineers than it does with companies. In fact it is more important to have individuals who make good judgements about pull requests and are responsive than it is to have all companies represented. There are an awful lot of healthy projects where only one person has commit access to the 'official' tree. > 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. If we get to that point, I think we've failed. It means we've got a broken process. I prefer to not borrow trouble on this issue. Start with something simple where only a few engineers have commit access to the 'official' tree. Allow everyone else to have their own separate repo (preferably on the same server, but not required) and send pull requests to the top maintainers. See how it works. If there are problems, then we can talk about more sophisticated controls. > 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. IANAL, but additional licensing terms must be taken very seriously. It makes it a different license. That particular clause is very definitely not an open-source term because it restricts the purpose that the code can be used for. I too would love to see the FAT package pulled into the main tree, but I think the license really needs to be resolved first. > 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? Pretty please? Yes? g. ------------------------------------------------------------------------------ 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
