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