On 9 October 2014 14:07, Michal Simek <mon...@monstr.eu> wrote: > Hi, > > On 10/08/2014 10:09 PM, Tom Rini wrote: >> On Wed, Oct 08, 2014 at 10:58:24AM +0200, Michal Simek wrote: >>> Hi, >>> >>> On 10/07/2014 02:45 PM, Marek Vasut wrote: >>>> Hey, >>>> >>>> given that we now have most of the u-boot socfpga stuff in mainline, I >>>> decided >>>> it would be a good idea to list what we're still missing and we should also >>>> decide how to move on now. >>>> >>>> First thing I should probably clarify is the late acceptance of the socfpga >>>> patches. This is certainly not something we do regularly and is one of the >>>> worst possible practices to do, but this time it felt rather important to >>>> get >>>> the platform in shape, so this exception happened. Furthermore, all of the >>>> code >>>> in u-boot-socfpga should be based on u-boot-arm and should be submitted >>>> through >>>> the u-boot-arm repository, not directly to u-boot . >>> >>> Platform was in this shape for a while that's why I can't see the >>> reason why this happen. >>> >>> Tom: Does it mean that every platform which is not in good shape can >>> go directly to the mainline in any time? It is definitely something >>> which is good to know. >> >> So, it's a long standing thing where for non-core changes, deferring to >> the relevant custodian about what's going to come in close to the >> release is what's done. So yes, I grilled Marek about what non-socfpga >> things would be impacted by the changes (RPi) and if he'd tested things >> there. It all had been through a few post/review cycles. >> >> There's an argument to be made that we shouldn't have let socfpga in, >> back in 2012 or should have pushed harder, sooner, to get more progress >> made on "real" platform support. > > AFAIK if platform is working in certain state and you are able to get > for example console than there is no problem to be in. There is nowhere > written what exactly should work that's why I can't see any problem > that socfpga is in if it is not causing compilation issues and have at > least minimum functionality. > > The question was if the problem was that Altera just failed because > didn't collect patches to any repo and sending it to Albert. > Or there was just misunderstanding that Albert expected that Altera > will do that and Altera expected that Albert will pick it up > because he is ARM custodian and none was listed for socfpga. > I have to defend Altera guys because if none is listed for SocFpga > the nearest maintainer is collecting patches. > > Then there was discussion that none did care about socfpga patches > and problem was resolved by creating socfpga repository and Marek became > custodian for it. Marek collected that patches to the new repo and > also I believe add new one and rebased them on the top of current tree > and send them out as one big 51 series which is not possible to even properly > review. > IMHO they should be sent separated to target exact audience which do care > about spi/i2c/watchdog/fpga/soc etc. But maybe that's just matter of taste. > > But I am still missing the point why that patches was that urgent > that they were merged to rc3 when it was claimed that socfpga was in a wrong > shape for a while. It means v2014.10 should be just another broken version > for socfpga and all this mess should be solved properly in 2015.01 via socfpga > repo. > > And because patches went into rc3 and yesterday Jeroen is reporting problem > on FreeBSD because of this merge.(http://patchwork.ozlabs.org/patch/397453/) > > Regarding your point that all "It all had been through a few post/review > cycles." > I don't think all things have been fixed. > Personally me I have reported here > http://lists.denx.de/pipermail/u-boot/2014-September/189741.html > (sha1: 0ae16cbb40a2881f6dfbe00fcb023ee7b548bc5c) > issue with checkpatch.pl which hasn't been fixed. > > Here is my ACK for one patch which is not present in mainline commit > http://lists.denx.de/pipermail/u-boot/2014-September/189747.html > (sha1: 2f210639c4f003b0d5310273979441f1bfc88eae) > > Make no sense to go through all patches but this is just an example. > > > I think it is something what we should discuss at u-boot mini summit > on Monday. I discussed this with Marek over IRC yesterday and I expect > he will ping me today (because of this email :-) ). > > If there is a problem because Albert is just too busy we should at least try > to find out > any reasonable way how to handle this. Like in Linux ARM-SOC custodian?
I think this traversing the actual development process in a different direction and it must be a valid point that need to discuss. Apart from this, I'm experienced an another isuue where some of the subsystem patches (say for example spi stuff) are pushed in a different direction. http://patchwork.ozlabs.org/patch/346015/ These are the qspi stuff from freescale, and I didn't understand why these goes into u-boot-arm/master. And there is no intimation of mine as well. Issue is that the driver itself is not in a proper shape, why does subsystem patches were pushed without the the review tag from a respective custodians. Please try to discuss this point as well "Each subsystem patch(es) should be pushed if and only if the respective custodian should marked the review tag" thanks! -- Jagan. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot