Dear Heiko,
In message 527B8BA7.2070605@denx.de you wrote:
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?
I have no idea. Not yet. Let's first define what we want to have, then think about how to implement it.
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?
Yes, this is perfectly fine. I just want to allow this at _any_ time, not only once per release (near the end of the release cycle). especially for releases where bigger changes get merged it may be precious information to know when the code stopped working.
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?
Well, one reason is efficiency. If the code builds fine, and does not cause efforts druing any of the ongoing work, it is more efficient to just keep it than to actively remove it, which would require active work. I. e. I want to reduce the work load on the maintainer(s) such that they only have to become active if such action saves even more effort. Actually it may even seem more efficient in some cases to perform minor fixing even of unmaintained boards than to remove them.
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.
But should we not also try to minimize efforts, especially on the custodians? If a board does not cause any trouble, we should not have to invent additional efforts for 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 ... :-(
I don't really understand this argument. The I2C code is either hardware independent (say, the command line interface code), or it is platform specific (say, the driver code for the I2C controller on a specific SoC), or it is board dendent (say, some specific twiddeling with I2C devices to perform some magic operations on a board).
In the first two cases the work wil have to be done in any case (except for the realy rare case that there are only old, unmaintained boards left using this SoC). An for the board specific code you can check if you need to adapt it by checking the board's test status. If the board is unmaintained, then we enter the "it hurts" branch, and drop the board.
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
Again: you don't need any knowledge about boards that are not affected by your I2C changes.
And if we have this test/delete cycle, I can be sure, that after a defined time all boards in mainline are working!
Yes, but the cost is additional efforts, and being more aggressive than necessary. I dislike both.
Best regards,
Wolfgang Denk