[U-Boot] livetime of boards

[Heiko Schocher]

Hello Wolfgang,

Am 07.11.2013 13:01, schrieb Wolfgang Denk:
> Dear "Andreas Bießmann",
>
> In message<527B7883.1080302 at 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
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany