[U-Boot] livetime of boards

[Wolfgang Denk]

Dear Heiko,

In message <527C767D.3070700 at denx.de> you wrote:
> 
> > 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.
> 
> With "once", I only meant, we once update the "livetimer" and collect
> all the time test reports!

But with your suggestion, the only stoprage for such information is
the life timer entry in the boards.cfg file.   Or would you suggest to
store additional information elsewhere?  Then we don't need the (then
redundant) counter in  boards.cfg ...

> > 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.
> 
> But in the long term I think, we have more work with old, unmaintained
> boards, then removing it. And if we remove boards actively, we maybe

YOu misunderstand.  My intention is to keep them as long as they do
NOT cause any efforts.  If they do, they are candidates for checking
for removal.

> force more the board maintainers (for examples corporates who have
> interest that the board stays in mainline) to really test them ;-)

Yes, but you organize more work for all of us.

> > 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.
> 
> Hmm... I am not really sure, if it is more work for removing a
> board or fixing compiling issues ...

If we have to fix compilation issues, that means that the board _IS_ a
candidate for removal.  I suggested to keep them as long as they do
"not cause any trouble" !

> > 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.
> 
> Hmm... :
> 
> pollux:u-boot hs [master] $ grep -lr HARD_I2C arch/powerpc/
> [...]
> arch/powerpc/cpu/mpc8xx/i2c.c
> [...]
> arch/powerpc/cpu/mpc8260/i2c.c
> arch/powerpc/cpu/mpc5xxx/i2c.c
> arch/powerpc/cpu/mpc824x/drivers/i2c/i2c.c
> arch/powerpc/cpu/mpc512x/i2c.c
> pollux:u-boot hs [master] $

THi sis all architecure support.  None of these files are board
specific.  None of them would be removed if you crap old boards.

> Is it worth to move the drivers to drivers/i2c/ and convert them to
> the new framework? Or is it better to delete them and the boards,
> which use them ... Ok, if we had such a "livetimer" without deleting
> old boards, you are right, I could do now:

How do you know which boards use these drivers?

> - search the boards, which use the drivers
> - search the state of this board
> - decide, dropping or convert ...
>    On which criteria whould this decision be done? I have no idea
>    if this boards exist anymore ...

There is no conflict with what I wrote - if you can find that only
"old" boards are using these drivers, then both the boards and the
drivers are candidates for removalk.  But you need to find this
correlation first, and verify that there are no "good" boards left
that use trhem do.

All of this is totally different of the mechanism how to determine
what are "good" or "old" boards.

> If we have only good boards, I have only one way -> convert. No
> time wasted for the above steps ...

It does not really matter when you have to check if there are "good"
users of this code left.  You have to do this in both cases - either
when removing the boards automatically, or when touching that code.

With your solution, you will probably have to do it twice, as you
cannot be really sure that the guy who removed the board support
verified that he was the last user of some global architecture support
code.

> I dislike additional efforts too (But the question is, needs removing
> old boards more effort than fixing them all the time maybe uselessly?).

Can you please re-read what I wrote?  I say we keep them as long as
they do NOT need ANY fixing.  If they do, this is a toalluy new game.

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
The following statement is not true.  The previous statement is true.