Hello Andreas,
Am 07.11.2013 12:24, schrieb Andreas Bießmann:
Hello Heiko,
On 11/07/2013 11:39 AM, Heiko Schocher wrote:
Am 07.11.2013 10:37, schrieb Andreas Bießmann:
On 11/07/2013 09:17 AM, Heiko Schocher wrote:
Am 06.11.2013 08:50, schrieb Wolfgang Denk:
In message20131105203736.GM5925@bill-the-cat you wrote:
<snip>
But you are right, that approach leads in a lot of conflicting patches ... but I think, we just pooled board information in boards.cfg, so this would be the right place in my eyes ...
Maybe we get such Information "a Boards is tested with current mainline" inform of an EMail with an Text "Board xy tested with commit mm. Please update livetime" ... and we can add a script, which updates the livetime for this board, so we can prevent conflicting patches ... ?
I agree here with Tom. Beside the possibility of conflicting pahces I see another problem here. We will get a lot of patches just for increasing the tested counter for a single board. These patches needs to be handled in some way. If we shift to some integrated system (gerrit comes to mind) this could be easier than today, but it will bind resources anyways. Therefore I think it is a bad idea to save a such often changing information in the source code repository.
I see this info just changing once when releasing a new U-Boot version.
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 maintainer could then see if he needs to pull out a board or if one else run the test before.
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.
Hmm... I hope we get a lot of such EMails ... and think, this is not a big problem ... Or, maybe, if we get a lot of such EMails, maybe we open a u-boot-testing list?
<snip mail proposal>
So (in current case Tom) should, before releasing a new U-Boot version, first call this script "collect_livetime_info" and he get:
-> 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.
Ok, if we have this info, we can show it wherever we want ...
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.
Yep! But collecting this infos can be done all the time.
... maybe "deleting boards" can be done automatically, but this is not a trivial job ...
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?).
See my proposal for the livetime counter:
livetime init value n (n=4) livetimer decrement on every new release livetimer set to n, if in release cycle comes a test report livetimer == 0 -> EMail to board maintainer, board reached end of live in mainline, please send test report. livetimer == -1 -> board get deleted
So all info is in boards.cfg availiable ...
Next question is what to do if the mail bounces ;)
Board gets deleted, as board maintainer didn;t send an update patch for boards.cfg ...
So, with such a solution, I see no big additional cost for adding such a feature (except the task "deleting old boards", which is maybe not trivial)
Do not understand me wrong, if we find another solution, I am happy also ... just spinning around ...
Me too.
<snip>
If we decide to delete older boards after n release cycles without testreports, we must not decide nor look in a database. We are sure, we have only "good and working" boards ... and we just do the necessary work for new features ... and we are sure, that we get back testreports within n release cycles ...
So let us decide first, if we want to go this way ...
Yes, we should introduce some mechanism to check when a specific board was last runtime tested. But I fear the overhead with patches that update a tested counter.
I thought with "decide": Do we want to delete "old boards"? With this, we do not need a "MAKEALL --check-boards -s at91" when we introduce new features, as all boards in mainline are in a well tested shape ...
Ok, two decisions:
- Do we want to collect board testinginformation?
I think we should do that i none way or another.
Yep.
- 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 ...
You do not have this problem when we descide to delete old boards!
bye, Heiko