Hello Wolfgang,
Am 07.11.2013 13:01, schrieb Wolfgang Denk:
Dear "Andreas Bießmann",
In message527B7883.1080302@gmail.com you wrote:
[...]
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.
Yep.
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.
Ok, how would look like such a web based service?
-> 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.
Oh, ok ... then we must look for another way.
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.
Hmm.. I thought we get a "test report" (however this looks like in the end) based on a commit id in u-boot/master ... isn;t this enough?
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.
Full Ack.
- 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".
Why the "not hurt case"? Is it really good to have a lot of boards, which compile clean, but we do not know, if the code really works?
I prefer to have in current mainline only boards, which really work or at least maintained... if a board maintainer did the work to bring it into mainline, it should be interested in "stay in" mainline. If this interest is lost and no other volunteers ... board is useless in mainline.
Code for old boards is not lost.
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.
Ok, that is a way to go, if we have for all boards the information, in which maintainstate it is ... but think of for example the new i2c framework, how much boards use I2C? I have to check now all this boards, decide to delete it or convert it ... very time consuming frustrating work ... and maybe for a lot of "do not hurt" boards only waste of time ... :-(
if we have a clean mainline state, where I know all boards are working the decision is clear, convert all ... and board maintainers will test it ... and we have always a clean compile state for mainline
And if we have this test/delete cycle, I can be sure, that after a defined time all boards in mainline are working!
bye, Heiko