[U-Boot] livetime of boards

[Wolfgang Denk]

Dear Heiko,

In message <527B8BA7.2070605 at 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.

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

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

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

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

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

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
Life would be so much easier if everyone read the manual.