[U-Boot] livetime of boards

["Andreas Bießmann" <andreas.devel@googlemail.com>]

Dear Wolfgang Denk,

On 11/07/2013 01:01 PM, Wolfgang Denk wrote:
> In message <527B7883.1080302@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)

You're right

<snip>

>>> 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.

Well, I think we should query that database on release and transform the
testing information to some information maybe stored in release code and
to trigger board maintainers to do tests.
Maybe the proposed lifetime counter is the correct tooling here.

We should introduce some service to gather testing information which
should have quite high throughput.
But we should also install some measures to see the 'liveliness' of some
board's tests in the released source code.

>> 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.

Sounds good, but doesn't fit to your next statement ...

>>> - 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.

Sounds good.

Best regards

Andreas Bie?mann