Hello all together,
On 11/07/2013 09:17 AM, Heiko Schocher wrote:
Am 06.11.2013 08:50, schrieb Wolfgang Denk:
In message20131105203736.GM5925@bill-the-cat you wrote:
<snip problem description>
Full ACK, we need some way to track which board is working with the current ToT or at least on a release basis.
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 :-(
Right, boards.cfg gets unhandy ... Hmm .. what with the column "Staus" ... instead of "Active" it would be more informative to have there the livetime counter, and a single digit saves some characters ;-)
I can't understand the status field at all, just for the record ;)
But you are right, that approach leads in a lot of conflicting patches ... but I think, we just pooled board information in boards.cfg, so this would be the right place in my eyes ...
Maybe we get such Information "a Boards is tested with current mainline" inform of an EMail with an Text "Board xy tested with commit mm. Please update livetime" ... and we can add a script, which updates the livetime for this board, so we can prevent conflicting patches ... ?
I agree here with Tom. Beside the possibility of conflicting pahces I see another problem here. We will get a lot of patches just for increasing the tested counter for a single board. These patches needs to be handled in some way. If we shift to some integrated system (gerrit comes to mind) this could be easier than today, but it will bind resources anyways. Therefore I think it is a bad idea to save a such often changing information in the source code repository.
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_testwhich 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.
Yes, that sound also good. I want to see the test information in the sourcecode, not somewhere on a wiki...
I think another place than the source code repository would be best for gathering such frequently changing information. Why not use some wiki other other web service for that purpose?
I don't want to search a web page for the information 'board X is not tested since ...' either. But we could easily write some scripts and add them to the source code repository to provide it.
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,
Hmm.. that works, if you have to touch some (some < 5) boards. But If you have to touch > 5 boards, this gets unhandy...
How about:
MAKEALL --check-boards -s at91
;)
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.
Why not save the SHA1 with the build-/runtime-tested information? Then we could easily build helper scripts to query that database when this board was last tested.
If we decide to delete older boards after n release cycles without testreports, we must not decide nor look in a database. We are sure, we have only "good and working" boards ... and we just do the necessary work for new features ... and we are sure, that we get back testreports within n release cycles ...
So let us decide first, if we want to go this way ...
Yes, we should introduce some mechanism to check when a specific board was last runtime tested. But I fear the overhead with patches that update a tested counter.
Best regards
Andreas Bießmann