Dear Tom,
In message 20131105203736.GM5925@bill-the-cat you wrote:
We have the real problem, that we have a lot of old boards, which are unmaintained in U-Boot, and we have no chance to find out, if this boards are longer used/tested ...
We also have a feature, lots of hardware support because lots of things don't change drastically, frequently. That's not to say that I wouldn't mind dropping old platforms (even that ones I have sentimental feelings towards), and would certainly like to see more and frequent sanity testing.
I think Heiko's idea of documenting test reports is pretty cool - but of course we need to discuss in detail how to implement this, and also decide wether we use this for (semi-automatic) code cleanup (by removing boards that have not been tested for a long time).
This problem comes up when we talk about doing big changes, and I think that's the right time to talk about things. And I think the answer should be, we try and convert things forward and when it's not obvious if things will still work correctly, or how to do it, that's when we need to make a hard push on the board maintainers to find some time to work on things.
Agreed. And here information how recently (or maybe even how frequently) a board has been tested (build tested, run on actual hardware) would come in really handy. we can probbaly automate build testing one way or another, but for actual runtime tests we will lways depend on the board maintainers, or board users.
So, the question raises, should we introduce a column in boards.cfg, which shows the "livetime" of a board support in U-Boot?
I sense a lot of conflicting patches.
Again I agree. Also, I fear that boards.cfg is becoming more and more unreadable by adding even more stuff. If I see this correctly, the maximum line length in boards.cfg already exceeds 360 characters :-(
So nstead of adding this information to boards.cfg we could probably use separate files for such information. We could provide tools to make test reports really easy, say something like
scripts/build_test scripts/run_test
which the user would just call with a "passed" or "failed" argument; the scripts could then auto-detect which configuration and which exact U-Boot version were in use, and send an email. Whether that would be a patch against the source code or something that get's auto-added to a wiki page is just an implementation detail. But if we had something like this, we could get a muchbetter understanding how actively boards are being tested.
So when you're once again doing some change that requires touching files for some othe rboards, you could simply check that database. If you see that 3 out of the last 5 releases have reported succesful run-time tests you will probably decide to accept the needed efforts, but when you see the last test report is more than 5 years old, you will probably rather decide to initiate a code removal process.
Best regards,
Wolfgang Denk