Dear "Andreas Bießmann", In message <527b7883.1080...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Simplicity boils down to two steps: Identify the essential. Eliminate the rest. - Leo Babauta _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot