Hello Wolfgang,
Am 07.11.2013 20:15, schrieb Wolfgang Denk:
Dear Heiko,
In message527B8BA7.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.
Ok.
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.
With "once", I only meant, we once update the "livetimer" and collect all the time test reports!
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.
But in the long term I think, we have more work with old, unmaintained boards, then removing it. And if we remove boards actively, we maybe force more the board maintainers (for examples corporates who have interest that the board stays in mainline) to really test 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.
Hmm... I am not really sure, if it is more work for removing a board or fixing compiling issues ...
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.
Hmm... :
pollux:u-boot hs [master] $ grep -lr HARD_I2C arch/powerpc/ [...] arch/powerpc/cpu/mpc8xx/i2c.c [...] arch/powerpc/cpu/mpc8260/i2c.c arch/powerpc/cpu/mpc5xxx/i2c.c arch/powerpc/cpu/mpc824x/drivers/i2c/i2c.c arch/powerpc/cpu/mpc512x/i2c.c pollux:u-boot hs [master] $
Is it worth to move the drivers to drivers/i2c/ and convert them to the new framework? Or is it better to delete them and the boards, which use them ... Ok, if we had such a "livetimer" without deleting old boards, you are right, I could do now:
- search the boards, which use the drivers - search the state of this board - decide, dropping or convert ... On which criteria whould this decision be done? I have no idea if this boards exist anymore ...
If we have only good boards, I have only one way -> convert. No time wasted for the above steps ...
So, yes, I think we do not need to delete the boards, just mark it broken ...
My hope with "delete old boards from mainline" is, that we become more testreports from board maintainers, as they (should) have interest that the board support stays in mainline. If they know, that the board is only marked as broken, old or whatever ... they maybe do not reserve the time for testing a board once a year ...
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.
I dislike additional efforts too (But the question is, needs removing old boards more effort than fixing them all the time maybe uselessly?). Is it really aggressive to want once a year a testreport from board maintainers? They get a lot of effort from the mainline for free...
bye, Heiko