From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Date: Fri, 12 Sep 2014 20:00:48 +0200 Subject: [U-Boot] u-boot-socfpga repository In-Reply-To: <20140911074618.51A09380CA2@gemini.denx.de> References: <201409110133.20669.marex@denx.de> <20140911120912.6E08.AA925319@jp.panasonic.com> <54112B64.5010104@monstr.eu> <20140911074618.51A09380CA2@gemini.denx.de> Message-ID: <541334D0.80109@monstr.eu> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Wolfgang, On 09/11/2014 09:46 AM, Wolfgang Denk wrote: > Dear Michal, > > In message <54112B64.5010104@monstr.eu> you wrote: >> >> I am not sure if you need to have separate repo to work like this. >> I am keeping zynq patches in my microblaze repo and sending pull request >> to Albert >> (or Tom now) and there is no problem with that. > > Well, technically of course this works, but it is far from perfect. > It works only for those who actually know about this. But anybody > looking at the U-Boot site for any zynq related stuff will have hard > times to find it. Please don't get me wrong I am just trying to understand what happened. We have MAINTAINERS file where we can simply add person who is responsible for specific SOC. I also believe that this is exactly reason why to have it. >From that file everybody can find out who should take the patches and and almost doesn't matter if git is at denx.de or somewhere else. But still all ARM patches should go through our ARM custodian not directly to Tom. get_maintainer.pl should also keep all interested people in the loop. > I think it is much better to make this knowledge public information - > and one easy way to do this is to have a separate repository for it, > which is listed on the custodians page, so everybody looking for it > will find all relevant information. Isn't that MAINTAINERS file already publicly available? Of course if you want to add the same information on wiki, I can't see any problem there. But creating separate repository for every SoC in u-boot seems to me just too much. >> In socfpga case I think there are guys from Altera who maintain it. > > Well, they maintain the stuff at rocketboards.org ; there are efforts > on the way to mainline stuff, but the process is not exactly > satisfactory. I highly appreciate that Marek volunteers to put > efforts in this. Definitely I also really appreciate that Marek volunteers to be responsible for socfpga. But that means that guys who are responsible for socfpga failed and they are not responding for patches which others are sending to mailing list for review. I am not closely following them but did this really happen? If they don't want to maintain their socfpga in mainline and Marek wants to do it I will definitely support Marek in this new possition to get things done properly but also I just want to make sure that this is really happen and isn't it just the part of misunderstanding how u-boot community is working. > As far as I am concerned, I support both Marek's and Masahiro's > requests. > > @ Marek and Masahiro: if we reach an agreement to create such repos, > please send me your SSH public keys that shall be used for > these. Also, what should the names be - u-boot-socfpga ? > And u-boot-uniphier ? [But is there not a chance that Pana- > sonic might have other SoCs that might be mainlines? So > maybe we should use u-boot-panasonic instead?] If they want to have separate repository because they think that it is better then their current one then sure why not to create them. Having arm SOC sub maintainers is definitely good concept but I am just not sure that creating separate repository fully solve this. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: