Dear Reinhard Meyer,
In message 4C5DE9F7.4070701@emk-elektronik.de you wrote:
- If the patch is simple enough reasoning might be sufficient.
Might. But things might go wrong. Turn around - Murphy is standing right behind you.
- 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
Adding a bad driver can break ALL boards. You just have to mess up the Makefile.
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>)
CONFIG_<board> should always be avoided and replaced by an appropriate CONFIG_<feature>.
- If its a rework, it should be shown working on at least one board in
each architecture (if it is a shared source)
That's what happens often, and turns out to be unreliable often, too.
- If nobody but the submitter is able/willing to test the patch, what
do we do then?
If nobody complains, it goes in.
Q: who resolves conflicts in very common files like MAINTAINERS, boards.cfg etc, they are bound to have merge conflicts when you pull?
If that's the only problems, and if your code is based on reasonably current versions, I will fix these.
Q: boards.cfg does not appear to be completely sorted, its not even sorted by ARCH.
The file is mostly sorted, as described in the comment.
And using the vi command does sort the header of that file, too....
Not if you place the cursor (i. e. the '.') on the first non-comment line.
Best regards,
Wolfgang Denk