[U-Boot] ATMEL Custodians == /dev/null ??

Reinhard Meyer reinhard.meyer at emk-elektronik.de
Sun Aug 8 01:19:19 CEST 2010


Wolfgang Denk wrote:
Dear Wolfgang,
> I have no chance to test anything, so rather leave responsibility with
> someone who actually can do at least some testing, and who has an
> understanding of the architecture.
>   
Sure there are different levels of testing possible.

1. If the patch is simple enough reasoning might be sufficient.
2. If its a new driver, it has to be proven to work (reliably) on at 
least one board (other
boards cannot break since they won't use it), and it should be 
reasonably obvious that the new
code is not board specific, or (if REALLY unavoidable) that board 
specific parts are at least
obvious by using #if defined(CONFIG_<board>)
3. If its a rework, it should be shown working on at least one board in 
each architecture (if it
is a shared source)
4. If nobody but the submitter is able/willing to test the patch, what 
do we do then?
n. of course all must survive the MAKEALL test.
>> As a custodian I sure would need more help and advice on how to handle
>> certain situations. I would (for start) have to rely on advice from Wolfgang
>> or someone else.
>>     
>
> No problem.
>   
I'll collect Q&A in a text file, maybe one can make a FAQ out of it later.
>> And as a custodian for AT91 I would mostly collect my own patches,
>> <sarcasm> review them, apply them after 2 weeks of nobody commenting on them
>> </sarcasm> and once in a while ask Wolfgang to pull them to mainstream?
>>     
>
> Right. And please don't forget the testing :-)
>   
That's implicit on my own patches. They are either of type 2. or type 3. 
as above ;)
> If you are willing to take that responsibility, please send me (off
> list) your SSH public key so I can give you write permission to the
> custodian repository.  And thanks in advance.
>   
Yes. And the first Qs:
Q: how do I get a key pair, and where do I find it?
A: I'll figure that out tomorrow, I think my system has generated one 
during install...
Q: it should be save when everyone knows the public part, why not on the 
list?
A: its not necessary...
>> PS: from messages in Atmel forums I notice that many users use some branched-off
>> old versions of u-boot and (almost naturally) have issues with that.
>>     
>
> I'd be happy to have working support for them in mainline.
>   
It is actually working in the mainline, I compiled ATNGW100 and 
AT91SAM9XE-EK
out of mainline and both worked out of the box (apart from that AVR32 
CFI issue).

I should put our new board's support files as patches out soon, even if 
they are not final, to
give others a glimpse how to add the new features to their boards. That 
raises the next few Qs:
Q: who resolves conflicts in very common files like MAINTAINERS, 
boards.cfg etc, they
are bound to have merge conflicts when you pull?
Q: boards.cfg does not appear to be completely sorted, its not even 
sorted by ARCH.
And using the vi command does sort the header of that file, too....

Best regards,

Reinhard


More information about the U-Boot mailing list