Dear "Andreas Bießmann",
In message 527B7883.1080302@gmail.com you wrote:
The saved information how often a board was runtime tested with the correct SHA1 of the u-boot/master could be quite useful. In the end just the last tested commit will be interesting but it could give some information how often that specific board is used. The information must not be generated by a board maintainer ... the
s/must not/need not/ (faux ami in action, I guess)
maintainer could then see if he needs to pull out a board or if one else run the test before.
I fully agree - everybody should be able to provide such test information. Actually it would be a big help to board maintainers as well if these would get test reports from actual users of the hardware.
If we would save this in the repository we do not have this information in time. If we send the information to a list we need to parse it or use some other tool to provide the information. Beside that we will pollute the list with status updates about boards being tested. It could be hard to find real patches in that information flood then.
Agreed too. I doubt if a mailing list makes sense to collect such data. It would probably be more efficient to provide a web based service for this. It just has to be easy to submit reports, and to query the status for boards.
-> one livetime counter patch for current release -> one list for boards which reach end of life -> one list for boards, which should be deleted
Good idea, but the information could also be saved on a website or in another database. It should be easily filled by the tester and also easily queried by wherever is interested in.
Agreed. I definitely do not want to see such trafic on the regular U-Boot mailing list.
All Infos are "release info" I think, and fully fit in the commit for the new release ...
I also think that should be done on release only.
Why? To me it makes a lot of sense to also collect information on intermediate snapshots.
I think deleting should be done in next release then to give the board maintainer some time to check the boards. On a new release the board maintainer should be mailed that in the next release the board will be removed. We should also store this somewhere in the code (status in boards.cfg?).
Next question is what to do if the mail bounces ;)
Mail bounces (and new address of maintainer cannot be found, and no other user volunteers to take over maintenance) => board is unmaintained => board gets removed.
- Do we want to delete old boards automatically after we do not get some test reports after a time intervall?
And we should delete 'unmaintained' boards, when is to be discussed. I'm currently fiddling with at91 gpio and ask myself if I should adopt all the boards or just let them fail ...
I hesitate to automatically remove existing boards. Why would we want to do that? To reduce efforts, right? So I vote to keep boards as long as they are either maintained, or they at least "do not hurt". If a board just builds fine and does not cause any additional efforts we should keep it, no matter if there is an active maintainer or test reports or not. Only when a board becomes a pain to somebody - say, because it develops build errors, or wit would require efforts to adapt it to some new feature, _then_ we would check if this is one of the "precious" boards we want to keep or if it is just old cruft nobody cares about anyway. And only then I would remove it.
Best regards,
Wolfgang Denk