On Tue, Aug 26, 2014 at 03:47:34PM +0200, Hans de Goede wrote:

Hi All,

Albert lately seems quite busy, and has a somewhat largish turn around time for things like pull-reqs. This mail is in no way intended as a complaint against Albert, we all have personal lives, and we all have periods were we are more busy then other periods in our lives.

Agreed.

But now that we've Kconfig, and thus no longer have the big bad conflict causing boards.cfg to deal with, I wonder if there is any added value in all ARM pull-reqs going through Albert's u-boot-arm tree ?

I can understand that if some new ARM arch needs core changes that those then need to go through Albert's tree and that any dependent changes then need to be merged either after Albert's tree has been merged, or through Albert's tree.

But for a lot of SoC specific work, e.g. stuff only touching files under arch/arm/cpu/armv7/sunxi and under board/sunxi, I really see no benefit in going through u-boot-arm, and I wonder if it would need be better to instead send pull-reqs for merging directly into u-boot/master.

So, I don't take this lightly (I'd reached out to Albert a few days before this was sent out as well). For the moment at least, I'd like to take ARM sub-trees into master directly. And I ask that custodians run time test as much of their code as they can and be very clear if they're touching code that's not strictly within their domain.

And I'll put on my "I work at an ARM producing semiconductor vendor, I should be able to get some ARM questions answered if I can't figure it out" and take some forms of more core ARM patches, depending on their need/complexity/etc.

With that said, I'm going to take u-boot-arm/master and put it through some tests locally for build / run-time, and then start picking up patches. I'm thinking I'll extend my informal approach of posting public patchwork bundle links in #u-boot to posting the URL on the ML for a day or so as well.

Thanks all!