[U-Boot] Should ARM custodian tree pull-reqs still go through the ARM tree ?

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140828/3472cf58/attachment.pgp>