On Thursday, October 09, 2014 at 10:37:52 AM, Michal Simek wrote:
Hi,
Hi!
I changed the subject, since it long didn't match the topic.
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.
This was not the case in here. The platform was completely unusable.
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.
It was not Altera guys who started submitting patches to put this thing in shape. Altera only realized that things started to move after Pavel sent the initial blob-of-a-patch . Since then, we are moving forward.
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.
Patches which were contained to the architecture for the most part, mind you. The rest were fixes for issues which appeared during this development, thus fixing issues in U-Boot.
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.
I fully agree on this part.
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.
Yes, this would mean that another broken version would be released even though the fixes were available. This doesn't sound right to me.
And because patches went into rc3 and yesterday Jeroen is reporting problem on FreeBSD because of this merge.(http://patchwork.ozlabs.org/patch/397453/)
This problem was discovered in a patch which was first posted to the list on Feb. 19 ( http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/180797 ), which is before 2014.04 release and was not discovered through the review process.
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.
And I explicitly noted that the FPGA stuff still has a couple of checkpatch issues right in the subsequent email [1] . Processing all the checkpatch issues of that file would make the resulting patch a horrid mess instead of producing a well contained set of patches.
[1] http://lists.denx.de/pipermail/u-boot/2014-September/189745.html
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)
Apologies, this one was indeed missed.
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 :-) ).
I agree we should discuss this on the minisummit. But what is "this" topic exactly? Do we have a list of topics we need to discuss somewhere, so this one can be added there ?
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 don't this Albert is the problem, I am starting to suspect we simply lack custodian manpower in general. And I also suspect we're not quite inviting and attractive crowd, which is something we should discuss too ...