[U-Boot] livetime of boards

[Wolfgang Denk]

Dear "Andreas Bießmann",

In message <527B7883.1080302 at 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)

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

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

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

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

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

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


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Simplicity boils down to two steps: Identify the essential. Eliminate
the rest.                                               - Leo Babauta